[erlang-questions] Local namespaces in case/try

[Michael Turner]

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.
-------
case do_something() of
     {error, Error} -> Error;
     {ok, Result} ->
          case do_another() of
              {ok, Result} -> Result;
              {error, Error} -> Error
          end
end
-------

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
<carlsson.richard@REDACTED> 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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions