[erlang-questions] Local namespaces in case/try

Sergei Lebedev <>
Tue Jul 10 12:52:30 CEST 2012

Your argument makes sense, but I wonder why list comprehensions don't follow this design decision? Of course, from the implementation point of view the answer is obvious -- list comprehensions are compiled to functions, which indeed have a separate namespace. But for me, as a user, it's one more rule to learn; I think scoping rules should be consistent, especially if the goal is to keep Erlang semantics as simple as possible.

-- Sergei

On Jul 10, 2012, at 2:30 PM, Richard Carlsson wrote:

> 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.
>    /Richard
> 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:
> 	let
> 	    Pat_1 = Expr_1,
> 	       ...
> 	    Pat_n = Expr_n
> 	in
> 	    BodyExpr
> 	end
> 	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.)
> _______________________________________________
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list