From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA08898; Mon, 11 Jun 2001 13:23:50 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA09034 for caml-list@pauillac.inria.fr; Mon, 11 Jun 2001 13:23:50 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA30156 for ; Sun, 10 Jun 2001 20:28:45 +0200 (MET DST) Received: from sarg.Ryerson.CA (sarg.ryerson.ca [141.117.18.117]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f5AISij25250; Sun, 10 Jun 2001 20:28:44 +0200 (MET DST) Received: from sarg.Ryerson.CA (IDENT:dmason@localhost [127.0.0.1]) by sarg.Ryerson.CA (8.9.3/8.9.3) with ESMTP id OAA09593; Sun, 10 Jun 2001 14:28:43 -0400 Message-Id: <200106101828.OAA09593@sarg.Ryerson.CA> To: Damien Doligez cc: caml-list@inria.fr Subject: Re: [Caml-list] Evaluation Order In-reply-to: Your message of "Sun, 10 Jun 2001 19:59:11 +0200." <200106101759.TAA0000023297@beaune.inria.fr> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Jun 2001 14:28:43 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> On Sun, 10 Jun 2001 19:59:11 +0200 (MET DST), Damien Doligez said: > The original argument about optimizations is still as valid as it > ever was. The real problem is that there is a conflict between > left-to-right evaluation order and currying. Consider the > expression: > f e1 e2 e3 > It only looks like the application of f to 3 arguments. In reality, > it is a nested expression with three function applications. If you > want to evaluate it in left-to-right order, you have to do the > following: >[...] > If you want to optimize this to get something as efficient as O'Caml > currently is, you have to know that f doesn't do any side-effect > before receiving all its arguments, which is generally impossible. > With right-to-left, the compiler doesn't have to know anything about > f. This is also addressable with my suggestion (which I posted last night, but hasn't made it to the mailing list yet) of annotating results of functions that cause a side-effect. So, in your example, instead of the existing: # let x = ref 0;; val x : int ref = {contents=0} # let f w y = incr x;let x' = !x in function z -> w+x'+y+z;; val f : int -> int -> int -> int = you would get instead: val f : int -> int -> (int -> int effect) effect = now when you apply it: f e1 e2 e3 you get an error if e3 is also an effect value, because the order of evaluation between the evaluation of (f e1 e2) and (e3) might cause a problem. So you would be forced to rewrite it as: let f' = f e1 e2 in f' e3 or let e3' = e3 in f e1 e2 e3' whichever reflected the order of evaluation that you want. Note that you would not get an error if e2 was an effect value because it must be evaluated (because of ml's strict semantics) before f is applied to it, and it doesn't matter whether e2 is evaluated before or after (f e1) is. Similarly, it does not matter if e1 is an effect value because it has to be evaluated before f can be applied to it. (Note that if f was an expression that itself was an effect, this wouldn't be true.) If e1 and e2 were *both* effect values, then there would be a conflict between them and you would get a compilation error. (Note that in my other posting I suggested a refinement of this that would get finer granularity on the conflicts, but the principle is the same.) This is somewhat related to monads, but with ocaml's strict semantics it need not be as intrusive as monads. ../Dave ------------------- 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