[erlang-questions] Local namespaces in case/try

Richard Carlsson <>
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.]

Extension 1:

	    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 mailing list