[erlang-questions] Local namespaces in case/try
Wed Jul 11 03:27:53 CEST 2012
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
the variable x is initialised, and if it is good enough
for Java to say that after
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
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
local Result, Error in
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.
More information about the erlang-questions