in reply to Re: Re: Order of operations, mutators, aliasing and whammies
in thread Order of operations, mutators, aliasing and whammies

Not defining order of evaluation leaves more possibilities open for optimalizations. Consider for instance the expression: 
    f ($a) + g ($a)

[download]
If you define an order of evaluation, it would probably be: 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

Replies are listed 'Best First'.
Re: Re: Order of operations, mutators, aliasing and whammies
by Jenda (Abbot) on Sep 09, 2003 at 14:05 UTC

    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]
      Say, you have a defined order of evaluation, and you define the order of evaluation for comma in list context from left to right. You also have lazy evaluation.

      Now, in the following expression, which one will be evaluated first, g() or h(): 

          sub f ($$) {$_ [1] && $_ [0]}
    f (g (), h ())

      [download]

      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]

In Section Meditations