Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Undefined evaluation order
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-10-11 (19:48)
From: Brian Rogoff <bpr@b...>
Subject: Re: Undefined evaluation order
On Tue, 10 Oct 2000, Thorsten Ohl wrote:
> Maybe I have ben brainwashed by too much Fortran, but depending on
> side effects in the evaluation of function arguments that change the
> result according to the evaluation order is not good style, IMHO.

I suppose I could claim to be brainwashed by too much Ada and C as well,
but somehow I am no longer enthralled by the lack of specified evaluation
order in those languages, even though I like both of them (not as much as 
OCaml of course :-).

BTW, in the particular case I mentioned, it wasn't function arguments but 
record/tuple expressions, as I was building an structure from a file read. 
It doesn't seem like bad style at all, in fact it seemed quite natural, 
only it doesn't work in OCaml, but would be fine SML.

> Explicit `let' bindings are clear and improve the likelihood that the
> author will still be able to understand his/her code a few year later
> significantly.

I don't believe that it improves understandability. Fix the evaluation
order to be left-to-right and the code is more understandable IMO. 
Explicitness doesn't necessarily imply greater readability/understandability.

Obviously, clarity is in the eye of the beholder, and probably depends on
your experiences as a programmer. I find the explicit let for sequencing 
redundant and distracting. Of course, if evaluation order were defined to 
be right-to-left I would use let bindings to force left-to-right because 
r-t-l is SO unnatural. 

> I agree that leaving this important chunk of the semantics unspecified
> is not nice, but closing the door on parallelism forever would be much
> worse, IMHO.

Arguments about optimizations in the bytecode compiler and parallelization 
are good arguments. The question is whether these outweigh the obvious
drawbacks. I don't think specifying evaluation order closes out
parallelism forever, since you can extend the language with explicit
parallel sequencing constructs if this were to ever become important. 

> (Only half-joking) There should be an option in the compiler
> randomizing evaluation order for debugging ...

That would be a good even if we had a specified order, so that you don't
inadvertently write code with such dependencies. 

-- Brian