[erlang-questions] Local namespaces in case/try

[Dmitry Groshev]

Exactly what I was talking about. I can't see any sense in bloating the 
code with nonsensical functions just to get something let-like -- AFAIK, 
every functional language out there has a local namespace for such 
constructs. Moreover, there is a huge inconsistency right now with list 
comprehensions that have their own namespace because of their 
transformation to functions:

test1() ->
    [begin
         _A = X,
         ok
     end || X <- [1, 2, 3]],
    _A = 1.

test2() ->
    case 2 of
        _A -> _A
    end,
    _A = 1.

I think it's a sign of a bigger problem with Erlang as a language: we have 
an amazing BEAM, some brilliant libraries, a lot of godlike developers, but 
Erlang as a language evolves extremely slow. One reason that I can think 
about is a lack of ultimate authority that can decide what is right and 
what is wrong — theoretically there is a EEP process (and some proposals 
are out of EEPs scope, like an e2 thing), but in practice some EEPs are 
here for years (like Frames proposal or JSON BIFs) and nothing really moves 
on. 

On Tuesday, July 10, 2012 1:40:17 PM UTC+4, Sergei Lebedev wrote:
>
> Richard, 
>
> 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. 
>
> -- Sergei 
>
> On Jul 10, 2012, at 1:02 PM, Richard Carlsson wrote: 
>
> > On 07/10/2012 10:43 AM, Dmitry Groshev wrote: 
> >> case do_something() of 
> >>     {ok, Result} -> Result; 
> >>     {error, Error} -> Error 
> >> end, 
> >> case do_another() of 
> >>     {ok, Result} -> Result; 
> >>     {error, Error} -> Error 
> >> end, 
> >> 
> >> Result and Error are bound in first case and we will probably have a 
> >> match failure in second one. Compiler warns about this, but it's still 
> >> very unwieldy to fix it with names like Error1, Error2, etc. 
> > 
> > Take it as a sign that you should break out those case expressions into 
> separate functions, or restructure the code in some other way. 
> > 
> >    /Richard 
> > _______________________________________________ 
> > erlang-questions mailing list 
> > erlang-questions@REDACTED 
> > http://erlang.org/mailman/listinfo/erlang-questions 
>
> _______________________________________________ 
> erlang-questions mailing list 
> erlang-questions@REDACTED 
> http://erlang.org/mailman/listinfo/erlang-questions 
>

On Tuesday, July 10, 2012 1:40:17 PM UTC+4, Sergei Lebedev wrote:
>
> Richard, 
>
> 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. 
>
> -- Sergei 
>
> On Jul 10, 2012, at 1:02 PM, Richard Carlsson wrote: 
>
> > On 07/10/2012 10:43 AM, Dmitry Groshev wrote: 
> >> case do_something() of 
> >>     {ok, Result} -> Result; 
> >>     {error, Error} -> Error 
> >> end, 
> >> case do_another() of 
> >>     {ok, Result} -> Result; 
> >>     {error, Error} -> Error 
> >> end, 
> >> 
> >> Result and Error are bound in first case and we will probably have a 
> >> match failure in second one. Compiler warns about this, but it's still 
> >> very unwieldy to fix it with names like Error1, Error2, etc. 
> > 
> > Take it as a sign that you should break out those case expressions into 
> separate functions, or restructure the code in some other way. 
> > 
> >    /Richard 
> > _______________________________________________ 
> > erlang-questions mailing list 
> > erlang-questions@REDACTED 
> > http://erlang.org/mailman/listinfo/erlang-questions 
>
> _______________________________________________ 
> erlang-questions mailing list 
> erlang-questions@REDACTED 
> http://erlang.org/mailman/listinfo/erlang-questions 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120710/08099e48/attachment.htm>