[erlang-questions] Local namespaces in case/try

Dmitry Groshev <>
Sun Jul 15 12:01:08 CEST 2012


Robert, language *is* schizophrenic right now thanks to list 
comprehensions. 

[A || {ok, A} <- B] %% there is no A outside this LC
case hd(B) of
    {ok, A} -> A
end
%% and now we have A bound. Feels like asylum

In my opinion, there are only two ways to make it less so:
-do some magic and rework list comprehensions so they export their 
variables — it's hard with current LC implementation, but it's doable. It 
will break some code for sure;
-rework case/if/receive statements to introduce their own namespaces. It 
will not break any code that compiles without warnings, because reuse of 
variables outside of case/if/receive emits a warning right now.
The second one is better, I think.

On Sunday, July 15, 2012 5:01:39 AM UTC+4, Robert Virding wrote:
>
> Sorry for not getting into this discussion earlier but I am vegetating in 
> the country (also called being on holidays) at the moment and the my 
> internet connection is not what it should be.
>
> Go Joe! I agree with what you and both Richards have written. Just some 
> personal comments:
>
> - If you were to introduce a let with variable scoping then you would have 
> to do the same for if/case/receive as well otherwise you would get a very 
> schizophrenic language. One which would definitely be much more confusing 
> for beginners than it is today. It would also mean that let/if/case/receive 
> wouldn't export variables, only return values, which would mean that the 
> original code would be useless anyway.
>
> - Even if funs/comprehensions behave differently from the rest their 
> behaviour is quite logical within the erlang context. For a fun to *export* 
> a variable would be completely crazy as it is defined in one place and 
> executed in another; where and when would you see the exported value? For a 
> comprehension which value of a variable should you see?
>
> - Having a variable referring to the same value in the whole function 
> clause body maybe different but it is actually very simple to grasp; 
> actually much simpler than having scopes.
>
> - As has been pointed out it is not a compiler problem, having scopes is 
> actually easier.
>
> Robert
>
> ----- Original Message -----
> > On Tue, Jul 10, 2012 at 12:00 PM, Dmitry Groshev
> > <> wrote:
> > > 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.
> > 
> > No that's not the reason.
> > 
> > There is no ultimate authority. Change is driven by the interplay of
> > several factors:
> > 
> >       - consensus (ie general agreement that something is good)
> >       - payment (the people who finance Erlang pay to have something
> >       done)
> >       - voluntary effort (individuals make changes, which are then
> >       adopted)
> > 
> > As regards the changes you suggest:
> > 
> > 1) Millions of lines of code have been written with the assumption
> > that if you see a variable twice
> > in the same lexical scope it has the same value. Changing this would
> > mean that all old code
> > must be retested and modified.
> > 
> > 2) When funs and list comprehensions where introduce the lexical
> > scoping rules where changed,
> > but there were no requirements for backwards compatibility
> > 
> > 3) A change like this invalidate all existing Erlang books and all
> > books in the pipeline.
> > Lack of good documentation is probably our single greatest problem,
> > so
> > we don't like changes that
> > invalidate all old documents.
> > 
> > 4) Something like frames and JSON bifs is being implemented and will
> > be released
> > as soon as it is stable. And yes there is slow progress on things
> > that are
> > not financed. The priorities for development are set by the people
> > who
> > pay for the development.
> > This means in practice that stuff that is need for Ericsson products
> > gets prioritized.
> > 
> > 5) Slow development of a language is a sign of maturity - languages
> > that are over twenty years old don't
> > change quickly. Most effort has not gone into language development
> > but
> > into the run-time system.
> > As each new generation of multicores has come along the system has
> > evolved to accommodate them
> > We want to keep the language constant, while adapting the run-time
> > system to modern architectures.
> > This takes priority over language changes.
> > 
> > 6) If you made a change like this and distributed the code somebody
> > who read the code later would not
> > know what the code meant. You can't have the same syntax for
> > something
> > in a program that means two different things
> > at two different times.
> > 
> > 7) I'm not against change as such - but we do have to take backwards
> > comparability seriously for many reasons.
> > We want to improve the system, subject to the condition that we don't
> > break the existing stuff. Even small change
> > require a lot of work, it's not just a question of changing the
> > parser
> > and compiler. All third-part tools have to be changed
> > the dialyzer, quickcheck, eclipse IDE, refactoring tools etc.
> > 
> > 8) Erlang could do with some major changes - I proposed erl2 a while
> > back but these changes are too
> > dramatic to be accommodated in a incremental and backwards compatible
> > manner. I perceive erl2 as a code generator
> > that produces regular erlang programs.
> > 
> > /Joe
> > 
> > >
> > > 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
> > >> > 
> > >> > http://erlang.org/mailman/listinfo/erlang-questions
> > >>
> > >> _______________________________________________
> > >> erlang-questions mailing list
> > >> 
> > >> 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
> > >> > 
> > >> > http://erlang.org/mailman/listinfo/erlang-questions
> > >>
> > >> _______________________________________________
> > >> erlang-questions mailing list
> > >> 
> > >> http://erlang.org/mailman/listinfo/erlang-questions
> > >
> > >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > 
> > > http://erlang.org/mailman/listinfo/erlang-questions
> > >
> > _______________________________________________
> > erlang-questions mailing list
> > 
> > http://erlang.org/mailman/listinfo/erlang-questions
> > 
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120715/257a35f1/attachment.html>


More information about the erlang-questions mailing list