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

[Richard Carlsson]

On 08/08/2011 09:33 AM, Jeff Schultz wrote:
> On Fri, Aug 05, 2011 at 10:47:29AM +0200, Richard Carlsson wrote:
>> On 08/05/2011 04:22 AM, Jeff Schultz wrote:
>>> While I appreciate the intent of Barklund's rule above, I don't think
>>> it plays well with Erlang's explicit left-to-right order of
>>> evaluation.
>
>> I think you have misunderstood something - or maybe I'm missing something
>> in your reasoning. Barklund's stated rule means that |(X = 8) + X| is just
>> as invalid in Erlang as |X + (X = 8)|, because even though it will work in
>> a left-to-right evaluation order (which is ultimately the order in which
>> the arguments _will_ be executed), it will not work in _any_ evaluation
>> order. The compiler therefore rejects it.
>
>> The nice consequence is that you can always naively reorder the arguments
>> of a function or operator call (in a valid program), because there's no
>> possibility that one affects the variable bindings expected of another.
>
> My point was that in a strict language with side-effects and an
> explicit evaluation order, the rule doesn't do anything useful.  It
> doesn't, for example, identify any code where the program will "go
> wrong" that won't be picked up by the use-before-definition check
> anyway.

As I said, the rule should be read as a general design principle for 
Erlang - it says that there has to *be* a check, one way or another (and 
at compile time), for potentially uninitialized uses - regardless of 
argument evaluation order. Otherwise, it's not Erlang. You could make a 
nonstandard dialect of Erlang that uses right-to-left evaluation order 
instead of left-to-right, and it would still be mostly the same 
language, but if you break the overall rule, then your language is no 
longer even Erlang-like.

For comparison, C is a "strict language with side effects" and lax 
evaluation order - but even if you fixed the evaluation order, there 
would be no rule that said that a C program containing a use of an 
uninitialized variable is not a legal program - it's just that its 
behaviour is undefined if you execute such a path at runtime.

Finally, it's best to keep the concepts of side effects and variable 
bindings separate. In a language like Erlang, variable bindings have 
nothing to do with side effects.

     /Richard