Browse thread
Undefined evaluation order
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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