Not defining order of evaluation leaves more possibilities
open for optimalizations. Consider for instance the
expression:
f ($a) + g ($a)
If you define an order of evaluation, it would probably
be:
- fetch the value of $a
- call f() with $a as argument, remember the return value
- fetch the value of $a
- call g() with $a as argument, remember the return value
- add the return values of f() and g().
Notice the twice fetching of $a. If the order of evaluation
isn't defined, you can first fetch the value of $a twice.
Even if you do fetch the value twice (instead of fetching
it once and remembering the results), doing it before calling
f() and g() could be a win due to an increased chance of
cache hits. It will also give you the opportunity to evaluate
sub expressions in parallel.
Last but not least, if the order of evaluation is defined,
people will start writing code that depends on this. This
will lead to fragile code, that will break if you swap the
arguments of an otherwise symmetric operator.
Finally, I don't see how lazy evaluation and a defined order
of evaluation combine to a happy programming language.
Perl6 will have a defined order of evaluation, and have
lazy evaluation. I wonder how Larry is going to pull off
that one.
Abigail
| [reply] [d/l] |
I don't think the problem is with having laziness and defined order of evaluation. It's side-effects per-se that create the problem. Which is why laziness is usualy only present in purely functional (free of any side-effects) languages.
The defined O-of-E could actually make the problem slightly smaller. Anyway IMHO the only thing Lary can do is to write a warning in the docs. "Don't mix laziness and side effects. If you do, don't come to us crying ;-)"
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
Edit by castaway: Closed small tag in signature
| [reply] |
sub f ($$) {$_ [1] && $_ [0]}
f (g (), h ())
The biggest problem I have with defining the order of evaluation
is that people will start to write code that depends on it.
It will mean that the code is fragile, and. specially in
combination with lazy evaluation, hard to understand. If the
order of evaluation is undefined, the code has to be correct,
no matter in which order it's evaluated. That makes code
easier to understand (because any order I choose is ok).
Abigail | [reply] [d/l] |