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
Re: 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-10 (19:25)
From: David McClain <dmcclain@a...>
Subject: Re: Undefined evaluation order
I second this opinion overall... I cut my teeth with respect to this when
writing C back about 20 years ago. Each individual statement in a program
carries with it the (implicit) assumption of simultaneous evaluation, unless
care is taken to indicate otherwise (e.g., Lisp (LET ...) vs (LET* ...) ).
Hence depending on a particular order of evaluation is seemingly dangerous,
not to mention confusing when switching between many different languages as
I must do... (Lately, with a mix of OCaml, SmallTalk, Dylan, and Lisp I have
even been getting confused about operator precedence!).

I think it is probably wrong for too many assumptions to be made in the
design and use of a language. Lisp is stellar in this regard, simply because
only one assumption is made - first operand is a function all the rest are
args. When one must switch between languages, it is horribly confusing to
have to get back into the mindset of the crowd that fancies their particular
language as the one and only...

Just my 2c...

- DM

-----Original Message-----
From: Thorsten Ohl <>
To: <>
Date: Tuesday, October 10, 2000 10:08 AM
Subject: Re: Undefined evaluation order

>Brian Rogoff <> writes:
>> For OCaml it appears that the perspective adopted is that the
>> programmer must make the temporal dependencies explicit. [...] it is
>> mentioned that this usually leads to clearer programs.  I'm sure the
>> bytecode compiler argument is valid, but not the code clarity one
>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.
>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
>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.
>(Only half-joking) There should be an option in the compiler
>randomizing evaluation order for debugging ...
>Thorsten Ohl, Physics Department, TU Darmstadt --
> [<=== PGP public key here]