[erlang-questions] Local namespaces in case/try

Robert Virding robert.virding@REDACTED
Sun Jul 15 03:01:39 CEST 2012 

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
> <lambdadmitry@REDACTED> 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
> >> > 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
> >
> >
> > _______________________________________________
> > 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
>

More information about the erlang-questions mailing list