[erlang-questions] Local namespaces in case/try

Michael Turner <>
Tue Jul 10 13:50:38 CEST 2012


Oops. On second thought, the first {ok, Result} in my suggested code
should really be "{ok, _}". Unless there's really some need to know
both the Result from do_something/0 and the Error from do_another/0,
in which case I suppose the original complaint still applies.

-michael turner

On Tue, Jul 10, 2012 at 8:43 PM, Michael Turner
<> wrote:
> I agree with Richard's reasoning, though I'm not sure I agree 100%
> with his prescription, in part because the following expression
> compiles just fine, even if it means something slightly different. If
> breaking the passage into two functions seems artificial, so what? You
> don't need to do that.
> -------

> -------
>
> And it's a difference that makes a (good) difference: why are you
> throwing out the first Error value anyway? If the first case/end
> clause throws away its values, why not just have "case do_something()
> of {error, _} -> ok; {ok, _} -> ok end", with a reasonable exception
> being thrown only when you don't get either of those two to match? And
> if you REALLY don't care what do_something/0 returns here, just call
> it w/o checking return value.
>
> -michael turner
>
> On Tue, Jul 10, 2012 at 8:03 PM, Richard Carlsson
> <> wrote:
>> On 07/10/2012 12:52 PM, Sergei Lebedev wrote:
>>>
>>> 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.
>>
>>
>> Funs and list comprehensions are indeed exceptions, and they do somewhat
>> complicate the language. Not everyone was happy when funs were added, for
>> example. I think funs tend to work because they are not so heavily used, and
>> you do get warnings about shadowed variables - something that I personally
>> thought was stupid to begin with, but eventually I realized that taken with
>> Erlang's normal scoping rules, it's best to avoid variable shadowing to keep
>> the code readable and maintainable.
>>
>> When it comes to list comprehensions, I think that they were added a bit too
>> quickly without much peer review of the finer details. It is nice to be able
>> to have only local scope for variables bound in generators, but on the other
>> hand it trips people up sometimes. But list comprehensions are well
>> delimited visually and don't usually cause confusion.
>>
>>    /Richard
>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list