Re: [Caml-list] Parameter evaluation order

["\"Márk S. Zoltán\"" <zoltan.s.mark@dravanet.hu>]

First of all, thank you for your answers. I thought a bit about this 
stuff - took a while. For reasons I am too embarrassed to explain, I 
prefer to answer a number of posts in one reply.

Alain Frisch wrote:

>
>It is, but your conclusion about left-to-right evaluation order is
>wrong. It's just that the binary application operator evaluates first
>its second argument (the function's argument), then its first argument
>(the functional value), and finally applies the function to the
>argument. An application (e1 e2) is semantically equivalent to:  (let y
>= e2 in let x = e1 in x y). Hence you get right-to-left evaluation order
>(but this is not specified).
>
>-- Alain
>  
>
I think I have to retract my equation completely: right now I do not see 
how *any* evaluation order would be implied by currying + strictness + 
side effects at all. Alain, in your model right-to-left evaluation is a 
consequence of defining (e1 e2) as you do; if it was defined to be (let 
x = e1 in let y = e2 in x y), we would have left-to-right evaluation. So 
the evaluation order is introduced by the definition of the functional 
application, not by strictness, currying etc.

I still wonder why did I implicitly assume this latter definition for 
function application. It seemed so straightforward, and it is also the 
order in which application of curried functions is usually explained 
(the explanation proceeds this way, it does not ever say that the actual 
ordering is also left-to-right). Sorry, guys.


Damien Doligez wrote:

> The problem (and historical reason for OCaml's unspecified order) is  
> that
>
> currying + side-effects + left-to-right evaluation order => inefficiency

That line of reasoning is fine with me, as I would not make use of a 
declared parameter evaluation order anyway, while I constantly rely on 
the performance of OCaml. Whoever relies on parameter evaluation order 
is probably capable of committing other hideous crimes, too.


brogoff wrote:

>It's a fun topic to chat about, but if you were allowed one change in the
>language, surely this wouldn't be it?  :-) 
>
Absolutely so. Tail recursion modulo cons is more important.

Regards

    M-