[erlang-questions] Local namespaces in case/try
Tue Jul 10 12:30:15 CEST 2012
On 07/10/2012 11:40 AM, 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.
What you have to understand first is that it's not a compiler limitation
- it's how the language was *designed*. The question about local scopes
is not new; it has been discussed several times over the years, and it
has been decided that mixing local scopes with Erlang's existing scoping
rules would create a schizofrenic language. Variable scoping in Erlang
is different from most other languages, but it's not random or poorly
designed. You just have to learn how to work with it, and the result is
usually (although not always) more readable code, when you do it right.
Here follows a quote from a mail that I had saved from 1996 by Håkan
Millroth when the addition of let-expressions was discussed:
"One of the really attractive characteristics of Erlang as we know it
today, is that all constructs in the language has simple semantics
that make sense also to imperative programmers.
I understand that several quite radical extensions to the language are
now being considered by the Erlang language designers. Several of these
extensions are, in my opinion, bad ideas. Below I explain why.
[I am not 100% sure that I describe the proposed extensions correctly
below. The reason for this is that there is, as far as I know, no
"official" description of the extensions.]
Pat_1 = Expr_1,
Pat_n = Expr_n
This introduces a new scope for the variables in Pat_1,...,Pat_n.
In most other functional langauges, this is how you introduce new
variables. It works just fine in these languages. Clean and nice. BUT:
Introduce this construct in Erlang and you get a bad design.
The principle in Erlang today is that a variable exists from its first
occurrence to its last occurrence in a clause. Very simple (maybe not
as elegant as the first method, but simple). It is also consistent that
case/if/receive follow this principle; this is not at all inelegant if
we consider case/if/receive as control structures in the language.
When we mix these two principles in one language, we get an inconsistent
and incoherent language design.
My advice to Erlang language (re)designers is: stick to one of the
principles. If you prefer the first one, then you should design a NEW
language which is consistent with that principle.
...[discussion of other language extensions removed]"
(I could note that another of Håkan's comments was: "'++' is OK.
However, there are several reasonable interpretations of what '--'
should do, none of them more natural than the others. Please, keep your
feet on the ground and forget '--'." Sadly, the advice was not taken.)
More information about the erlang-questions