Re: [Caml-list] Evaluation Order

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

> 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