[erlang-questions] How about a new warning? Was: Re: trouble with erlang or erlang is a ghetto

[Robert Virding]

----- Original Message -----
> On 08/04/2011 12:24 AM, Robert Virding wrote:
> > I must say that I find this a little strange. If the evaluation
> > order
> > of subexpressions is defined, which it is, then I would have
> > expected
> > that the whole effect of a subexpression would be visible in
> > "later"
> > subexpressions. Hence you could do things like:
> >
> > (X=8) + X
>  > foo(X = bar(42), X)
> >
> > but not
> >
> > X + (X=8)
>  > foo(X, X = bar(42))
> >
> > because of the evaluation order.
> 
> You could, yes, but it's not a good idea. For example, a refactoring
> that switches the order of arguments to a function would have to
> consider any bindings in calling occurrences and lift them out to
> preserve the evaluation order *and* the bindings:
> 
>    foo(f(), X=bar(), g(X))
> 
> must become
> 
>    V1 = f()
>    X = bar(42),
>    V2 = g(X),
>    foo(V1, V2, X)
> 
> or possibly
> 
>    foo(f(), begin X=bar(42), g(X) end, X)
> 
> if you want to switch the order of the last two arguments.

This wouldn't help as you still have an order dependency.

I don't have any problems with refactoring tools, I never use them. :-) Being old-school I prefer my code exactly as it is written, if I had wanted it in another way I would have written it in another way.

I view {X,Y} = foo(A) as *one* expression so think it is more logical to see all the effects of it after it has been evaluated, even the variable bindings. It is not a big issue as most people, including me, seldom write code where this would be an issue, although not handling bindings in this way could make some code a bit more verbose.

> The rule that all arguments are evaluated in the same environment
> makes
> the world a happier place. If I want Basic, I know where I can get
> it. ;-)

Yes, write my own. The next language on the Erlang VM, Ebasic, for real programming.

Robert