Three wishes

[Ola Andersson A (AL/EAB)]

> Richard A. O'Keefe wrote:> 
>
> Roger Price <rprice@REDACTED> wrote:
> 	Erlang allows variable name scope extrusion from if, 
> case or receive
> 	primitives, "Concurrent programming in Erlang", section 2.8.1.
> 
> "Scope extrusion" is a bad way to think about Erlang.
> A better way to think about it is to think of there being a *single*
> scope level for *all* variables in a clause;
> a variable which is defined in some but not all branches of a 
> conditional
> form is unavailable rather than out of scope.
> 
> 	I would like an option which supresses this scope extrusion, and
> 	makes the variables introduced within an if, case or receive
> 	unknown outside.  I would also like this option to be the
> 	default compiler behaviour.
> 
> This would massively break backwards compatibility, all in the name of
> adding a rather dubious feature (Erlang variables are not otherwise
> locally scoped, the proposed begin ... end feature not having been
> adopted).
> 
> 	The current scope extrusion is counter-intuitive, and adds
> 	unwanted complexity.
> 
> It is perfectly intuitive provided you first form your intuition.
> It is exactly what you get in Prolog and other related languages.
> And it does not *add* complexity, it *removes* it:  there is no notion
> of nested scopes in the language, only that certain variables 
> are known
> to have paths on which they are not defined.
> 
> 	Is there any case in which it is a "must have"?
> 
> Why yes, in the common case of things like
> 
> 	if X > Y -> Sign = 1,  Abs = X - Y
>          ; X < Y -> Sign = -1, Abs = Y - X
>          ; X ==Y -> Sign = 0,  Abs = 0
>         end,
>         ... use Sign and Abs ...
> 
> where the *point* of the conditional is to bind several variables
> rather than to compute a value.
> 

I believe the answer is no. There are no cases where you "must have" exports 
from case and so on. In the example above there are at least three different
ways to solve the problem whitout having to resort to exporting from the if statement.
I have _never_ used export from case, if or receive, nor have I ever felt a need for it. 

I would also like to see a compiler option that prevents such exports.
Wasn't there serious plans to actually make these exports, from case, if and receive,
compile error some 5-6 years ago?
I guess the backwards compatibility issues prevented that from happening.
Too bad.

I have noticed that people with a background in other programming languages,
like C, tend to use this export "feature" rather extensively. In fact, many
of them seem unable to write code whitout using it. A kind of mindlock.
They usually end up with functions spanning hundreds of lines of code with
a multitude of nested case statements exporting variables all over the place.
I have seen it in several projects and it is a nightmare to debug.
I my view it just encourages bad coding habits, like programming C in Erlang,
when exports from case are allowed.
I'm aware that it would not prevent bad coding to disallow it, but I believe
it would guide people in the right direction. (Away from thinking C that is..)
I realize that it would be difficult enforce this, considering the vast 
existing erlang code base, but a compiler option would be nice though.
/OLA.