Re: [Caml-list] Evaluation Order

[Brian Rogoff <bpr@best.com>]

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