[erlang-questions] How about a new warning? Was: Re: trouble with erlang or erlang is a ghetto
Mon Aug 8 11:10:51 CEST 2011
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
>> 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
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.
More information about the erlang-questions