Re: [Caml-list] Evaluation Order

["David McClain" <dmcclain1@mindspring.com>]

> > Use lots of lets to sequence operations. Avoid side effects like output
in
> > value returning operations, otherwise you'll want to use lets to
sequence
> > the outputs while getting the value. Write Haskellish code, by which I
> > mean try to push all of your refs and mutable values to the top level
and
> > have all of your library calls pure. Agitate to get this annoying
feature
> > fixed. Etc...
>
> Actually the side effects I was referring to have nothing to do with
> reference vars. In fact there are none in the code. Rather, the side
effects
> have to do with the order in which data are processed and sent along to
the
> next job upstream.

In fact let me be a bit more specific, by way of example...

The block convolution operation could be viewed as adding reverberation to a
data stream. The first function processes the entire stream. The second
operation writes out the remainder, the reverb tail, after the input stream
has been exhausted.

My mistake was writing

let ans = process_stream() + process_tail()

where both operations return a count of how many data samples had been
written to the output stream. I accidentally got the tail processing first,
which caused the anomalous output. The front of the output stream had too
much null data, and the final tail of the stream was chopped off.

The results of these two operations, integers, are arithmetically commutable
under addition. But what isn't commutable is the order in which these
operations occur. No current type checking in OCaml (or any other language
with which I am familiar) could help catch this mistake.

What is needed is some specification that indicates temporal preference, and
then the type checking mechanism must be enhanced to keep temporal order.
Most programs in OCaml probably have no preference, and in fact, a sense of
order is strongly discouraged in most FPL's -- e.g., Haskell.

I am saying that real-world applications for control systems do have strong
needs for these additional constraints. I am not being critical of OCaml or
any other language here. But my experience pointed out the need for even
more from programming languages than what we have today.

The major flubs of the past decades, Arianne, Therac, and many others, are
examples of systems in which not only the data types have to be ensured, but
also temporal orderings of function evaluation. We are rapidly adopting a
system with a foundation of dust when we come to rely so heavily on human
programmed computers to manage and treat our lives.

- DM


----- Original Message -----
From: "David McClain" <dmcclain1@mindspring.com>
To: "Brian Rogoff" <bpr@best.com>
Cc: <caml-list@inria.fr>
Sent: Saturday, June 09, 2001 4:12 PM
Subject: Re: [Caml-list] Evaluation Order


> > No, if Hebrew or Arabic were your native tongue you'd have exactly the
> > same expectation as you have now, which is that the events occur in the
> > order that you scan them while reading. What happens in OCaml now is
like
> > some weird boustrophedon.
>
> Huh? Hebrew and Arabic read from right to left, which is why I said what I
> did... A boustrophedon infers that the order changes to and fro in a
raster
> pattern. I won't argue the point about unspecified order of evaluation. I
> would argue for notation that indicates temporal preferences and helps to
> enforce them in the code.
>
>
> > Use lots of lets to sequence operations. Avoid side effects like output
in
> > value returning operations, otherwise you'll want to use lets to
sequence
> > the outputs while getting the value. Write Haskellish code, by which I
> > mean try to push all of your refs and mutable values to the top level
and
> > have all of your library calls pure. Agitate to get this annoying
feature
> > fixed. Etc...
>
> Actually the side effects I was referring to have nothing to do with
> reference vars. In fact there are none in the code. Rather, the side
effects
> have to do with the order in which data are processed and sent along to
the
> next job upstream.
>
> I would argue for something stronger here. The mistake was made as a
result
> of performing a commutative arithmetic operation between two results that
> should never commute in time. I think a sequencing operation and a type
that
> distinguishes objects that have specified temporal orderings is in order
> here.
>
> Otherwise we are left to astute programmers who have to be on their very
> guard continuously against unintentional misuse of evaluation order.
Humans
> are not trustworthy in the sense that machines are, which never tire of
> mundane tasks.
>
> - DM
>
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ:
http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives:
http://caml.inria.fr

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr