[Caml-list] Evaluation Order

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

I thought I would share an experience with all of you to solicit your
*constructive* comments.

I just rewrote my block convolution routine in pure OCaml native compiled
along with the inner loop in C/C++. This is necessarily a side effecting
program since it must alter the outside world of data. I had a statement in
OCaml that went something like this:

    let ans = fnx () + fny ()

where both fnx and fny are side effecting closures.

I consider myself a very experienced OCaml programmer, and I am so
accustomed to getting pristine results from OCaml, that I spent many hours
going through my C/C++ code looking for the error. I was getting anomalous
output values at the front of my convolution records, but everything else
worked just fine. I was convinced something was awry with my C code ---
whenever a problem occurs that's almost always where it is -- never in the
OCaml code.

I had forgotten about the evaluation ordering in OCaml being from right to
left. I am aware of the reasons for this, having studied the Zinc paper some
time ago. But the tendency to read implicit temporal ordering of operations
as left to right is a very strong psychological factor here. The problem,
once tracked down, was easily fixed by restating the routine as

    let ans = fnx() in
        ans + fny()

to force evaluation of fnx before fny.

I suppose if Hebrew or Arabic were my native tongue then the opposite
expectation would be true and I would have naturally written

    let ans = fny() + fnx()

and I would be no wiser about evaluation order here, since everything would
have worked properly.

I don't have a good answer to this problem, but I did want to point out the
one and only place where OCaml forced me to spend hours debugging a problem
caused solely by a clash of psychology and OCaml semantics. All of my other
debugging activities have, and will probably continue, to focus on C/C++ as
the likely culprit.

This problem will be permanently etched into my mind from now on, and I will
be sure to remember to avoid order dependent syntax.

The same problem occurs regularly in C, and I have become quite accustomed
and adept at avoiding these ordering problems. Good examples are to be found
among C preprocessor macrology. I just now have to remember that the same is
true of OCaml.

I had been lulled into a belief that OCaml was nearly perfect, while C/C++
is definitely not. The problem is not one of OCaml, but rather a clash
between normal psychological expectations and the programming language at
hand.

Since embedded realtime systems are chock full of temporally ordered
operations this must be one of the severe weak points in software control
systems. There must be a better way to guide human thinking here. Just as
OCaml has provided a system to look over our shoulders and force us to write
the correct things, there must be a way of doing something similar for
temporally dependent clauses.

Any thoughts? (other than that I was boneheaded here!)

- 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