Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Parameter evaluation order
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2005-08-26 (17:54) From: Márk_S._Zoltán Subject: Re: [Caml-list] Parameter evaluation order
```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

Alain Frisch wrote:

>
>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-

```