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 SAA29554; Sun, 10 Jun 2001 18:47:38 +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 SAA29394 for ; Sun, 10 Jun 2001 18:47:37 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5AGlZL00146 for ; Sun, 10 Jun 2001 18:47:36 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id JAA02657; Sun, 10 Jun 2001 09:47:25 -0700 (PDT) Date: Sun, 10 Jun 2001 09:47:25 -0700 (PDT) From: Brian Rogoff To: John Max Skaller cc: David McClain , caml-list@inria.fr Subject: Re: [Caml-list] Evaluation Order In-Reply-To: <3B237A77.E345823F@ozemail.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 10 Jun 2001, John Max Skaller wrote: > Brian Rogoff wrote: > > [Evaluation order] > > > The original arguments about optimizations > > and parallelism don't seem to have borne fruit, so it would be good to fix > > this. > > The question is whether we really want to encourage such > an obvious flouting of referential transparency as being > able to depend on the order of evaluation of the arguments > of the infix integer addition operator. Well, OCaml isn't referentially transparent, and it is strict to begin with. I agree that it would be awful if my argument was only about the order of evaluation of (+). > Perhaps binding record fields left to right makes sense, And tuples, and (::), and ... Why not make the default correspond to everyone's intuition? > but making evaluation order explicit by > > let a = f() in > let b = g() in > a + b > > seems to be good style to me (you only need to know that > Ocaml is an eager language). I agree completely. I even shove in prints to debug purely functional code (shame on me!) by adding "let _ = prerr_endline ... in" in such constructs. I also rarely use "and" when there are no dependencies (I see that kind of code) and only use it when there is a recursive definition. > You could also run into problems if you used some syntactic sugar such > as by using ocamlp4: the visible ordering mightn't be the final one > unless the p4 macros took special care to ensure this. Hmmm, I wonder if this is a problem for MetaML, which is a macro-like system based on SML? Any users on the list care to comment? As a digression, macros and generic functions seem to be one of the few places left where Lisp has some advantage over ML (IMO of course). It would be nice to surpass Lisp completely one day... -- Brian ------------------- 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