christian konrad wrote:
> But that seams really strange not to have a strictly defined order of 
> evaluation. Isn't that really bad if one would like to do some tail 
> recursion to get it compiled without recursion but as a loop?

Undefined order of evaluation allows more optimization.

Arguably, it may be confusing for the programmer (especially one who is 
used to relying on order of evaluation of arguments to a function 
call--a rather dangerous practice). But your remark about tail recursion 
is mistaken, i.e., you are suggesting that a call to a function inside 
an argument to another function might be tail-recursive, which is 
clearly impossible.

In your example, you had

   let rec readIn() =
      ....
      (input_line infile) ^ readIn()
      ....

Here we have arguments "input_line infile" and "readIn()" to the binary 
operation ^. It does not matter what the order of evaluation of the 
arguments is: readIn cannot be tail-recursive under any order, since the 
last thing that needs to happen is ^.

Best regards,

Andrej