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 TAA29993; Sun, 10 Jun 2001 19:59:12 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA29935 for ; Sun, 10 Jun 2001 19:59:11 +0200 (MET DST) Received: from beaune.inria.fr (beaune.inria.fr [128.93.8.3]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5AHxBL00979 for ; Sun, 10 Jun 2001 19:59:11 +0200 (MET DST) Received: by beaune.inria.fr (8.8.8/1.1.22.3/14Sep99-0328PM) id TAA0000023297; Sun, 10 Jun 2001 19:59:11 +0200 (MET DST) Date: Sun, 10 Jun 2001 19:59:11 +0200 (MET DST) From: Damien Doligez Message-Id: <200106101759.TAA0000023297@beaune.inria.fr> To: caml-list@inria.fr Subject: Re: [Caml-list] Evaluation Order Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >From: Brian Rogoff >No, this is a language problem. Lots of people who teach OCaml have mentioned >that this is an issue. If the clash with expectation is so great then that >You should always be careful about sequencing in imperative style programming, >but IMO this is one of those few things that SML does right that OCaml does >not. As you say, there is a very strong expectation that events occur in >the order that we read them. The original arguments about optimizations >and parallelism don't seem to have borne fruit, so it would be good to fix >this. 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: 1. evaluate f 2. evaluate e1 3. evaluate f (e1) (call the result f1) 4. evaluate e2 5. evaluate f1 (e2) (call the result f2) 6. evaluate e3 7. evaluate f2 (e3) 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. For years I thought that the only solution to this problem would be to move away from currying by changing the preferred programming style to passing tuples or records (as SML does). But people at INRIA are overly fond of currying for some reason. Now I think there's another solution. Let's just have different semantics for (f e1 e2 e3) and ((f e1) e2 e3) : f e1 e2 e3 should evaluate f, then e1, then e2, then e3, then do a ternary application. (f e1) e2 e3 should evaluate f, then e1, then do a unary application, then evaluate e2, then e3, then do a binary application. I think this solution should work, and retain all the efficiency of O'Caml. The question is, how much does it interfere with labels and optional arguments ? -- Damien ------------------- 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