[erlang-questions] Local namespaces in case/try
Dmitry Groshev
lambdadmitry@REDACTED
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
> > <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
> >
> _______________________________________________
> 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/20120715/257a35f1/attachment.htm>
More information about the erlang-questions
mailing list