Re: Re: Order of operations, mutators, aliasing and whammies

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

Comment on Re: Re: Order of operations, mutators, aliasing and whammies

Replies are listed 'Best First'.
Re: Order of operations, mutators, aliasing and whammies by Abigail-II (Bishop) on Sep 09, 2003 at 14:15 UTC
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]

Replies are listed 'Best First'.

Re: Order of operations, mutators, aliasing and whammies
by Abigail-II (Bishop) on Sep 09, 2003 at 14:15 UTC

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]