[erlang-questions] Local namespaces in case/try

[Richard O'Keefe]

On 10/07/2012, at 9:40 PM, Sergei Lebedev wrote:,
> 
> While this indeed *may* be a sign of a problem in your code, for the original example this is hardly the case. Splitting the function apart *only* because of compiler limitations sounds like an ad-hoc hack, not a real solution.

I have shown in another message how we can get exactly the intended effect,
in the language as it stands with no changes or extensions.

The most important point here is that we are ***NOT*** talking about
an accidental limitation where a compiler doesn't do something because
the authors were too lazy or too incompetent or too resource-limited
to do it or anything else like that.

There is a software engineering reason:

    It is simply a bad idea to use the same name for two different
    variables within a short stretch of code.  In my experience in
    Algol, C, Pascal, &c: if code that does that isn't buggy now,
    it soon will be.

There is a programming language reason:

    Languages that allow nested variable scopes require some sort
    of declaration marker than says which variables are new.
    I can think of a few exceptions (TCL, Icon, Fortran 66) where
    the default is that any variable in a function is local unless
    explicitly marked as global, but those languages do not allow
    nested scopes within a function.

    Erlang used not to have nested variable scopes at all.
    When funs were introduced, it got some, but it is still the
    case that one function-or-fun-clause = one contour.

    Changing this requires some sort of language change.

There is a backwards compatibility reason:

    Some programmers think that if it is good enough for Dijkstra's
    notation to say that after
	if p => x vir:= 1
	[] non p => x vir:= 2
	fi
    the variable x is initialised, and if it is good enough
    for Java to say that after
	int x;
	if (p) x = 1;
	else x = 2;
    the variable x is initialised, then it is good enough for
    Erlang to say that after
	if P    -> X = 1
	 ; true -> X = 2
	end
    the variable X is initialised.  This is especially important
    when the choices need to initialise several variables, and
    packing them up into an entirely artificial tuple and then
    unpacking it afterwards is both error-prone and unclear.

So what you really need is a way to say WHICH variables are
private to an expression.  Perhaps

	local Result, Error in
	    case ...
	local Result, Error in
	    case ...

where 'local' would only count as a keyword if immediately followed
by a variable name.


As for 'hacks', I remain to be convinced that using the same variable
for two different purposes in the same clause is a *SERIOUS* need.