[erlang-questions] Local namespaces in case/try

Joe Armstrong erlang@REDACTED
Tue Jul 10 14:41:54 CEST 2012


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
>



More information about the erlang-questions mailing list