>     It is well known that OCaml has undefined evaluation orders and that
> it uses right-to-left ordering. What is the rationale for that decision? 

The main reason was to accommodate the "push-enter" model used by the
Caml Light and Objective Caml virtual machines.  In this model,
arguments to curried functions are pushed on a stack, first argument
last, and then the code of the closure is entered.  (As opposed to the
"eval-apply" model, where the first argument is evaluated, followed by
one function application, then the second argument is evaluated,
followed by a second application, etc.)

The "push-enter" model allows a lot of nice optimizations for curried
functions, but entails right-to-left evaluation of function arguments.

Rather than "standardize" a right-to-left evaluation order, we decided
to leave the evaluation order officially unspecified.  At that time,
it was also believed that this could leave more flexibility for other
optimizations, e.g. the reordering of sub-expressions for minimizing
register use described in the Dragon book, and perhaps also for
parallel evaluation.

In retrospect, we overestimated the potential gains of such
optimizations, and actually never implemented any of them (nor
parallel evaluation), sticking to the same evaluation order in the
native-code compiler than in the bytecode interpreter.

>     Besides being surprising for lots of people, it is actually a little
> ugly to have to write explicit let bindings to force the order and when
> reading files which consist of long records;

Yes, I agree.  Even with good programming discipline, I get bitten
about once a year by the unexpected evaluation order.

In retrospect, perhaps we should have considered introducing "let"
bindings automatically to preserve left-to-right semantics within the
push-enter model (like Moscow ML does, I think), although this entails
a performance hit for the bytecode interpreter.

- Xavier Leroy