I wasn't talking about breaking backward compatibility, I was talking about some sort of -compile() option. Moreover, I doubt that anything will break even if this feature will become standart, because right now compiler throws an error/warning if one use a variable like that. On Tuesday, July 10, 2012 4:41:54 PM UTC+4, Joe Armstrong wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Jul 10, 2012 at 12:00 PM, Dmitry Groshev <<a href="mailto:lambdadmitry@gmail.com" target="_blank">lambdadmitry@gmail.com</a>> wrote:

<br>> Exactly what I was talking about. I can't see any sense in bloating the code

<br>> with nonsensical functions just to get something let-like -- AFAIK, every

> functional language out there has a local namespace for such constructs.

<br>> Moreover, there is a huge inconsistency right now with list comprehensions

<br>> that have their own namespace because of their transformation to functions:

<br>>

<br>> test1() ->

<br>>     [begin

<br>>          _A = X,

<br>>          ok

<br>>      end || X <- [1, 2, 3]],

<br>>     _A = 1.

<br>>

<br>> test2() ->

<br>>     case 2 of

<br>>         _A -> _A

<br>>     end,

<br>>     _A = 1.

<br>>

<br>> I think it's a sign of a bigger problem with Erlang as a language: we have

<br>> an amazing BEAM, some brilliant libraries, a lot of godlike developers, but

<br>> Erlang as a language evolves extremely slow. One reason that I can think

<br>> about is a lack of ultimate authority that can decide what is right and what

<br>> is wrong — theoretically there is a EEP process (and some proposals are out

<br>> 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.

<br>

No that's not the reason.

<br>

<br>There is no ultimate authority. Change is driven by the interplay of

<br>several factors:

<br>

<br>      - consensus (ie general agreement that something is good)

<br>      - payment (the people who finance Erlang pay to have something done)

<br>      - voluntary effort (individuals make changes, which are then adopted)

<br>

<br>As regards the changes you suggest:

<br>

<br>1) Millions of lines of code have been written with the assumption

<br>that if you see a variable twice

<br>in the same lexical scope it has the same value. Changing this would

<br>mean that all old code

must be retested and modified.

<br>

<br>2) When funs and list comprehensions where introduce the lexical

<br>scoping rules where changed,

<br>but there were no requirements for backwards compatibility

<br>

<br>3) A change like this invalidate all existing Erlang books and all

books in the pipeline.

<br>Lack of good documentation is probably our single greatest problem, so

<br>we don't like changes that

invalidate all old documents.

<br>

<br>4) Something like frames and JSON bifs is being implemented and will be released

<br>as soon as it is stable. And yes there is slow progress on things that are

<br>not financed. The priorities for development are set by the people who

pay for the development.

<br>This means in practice that stuff that is need for Ericsson products

gets prioritized.

<br>

<br>5) Slow development of a language is a sign of maturity - languages

<br>that are over twenty years old don't

<br>change quickly. Most effort has not gone into language development but

into the run-time system.

<br>As each new generation of multicores has come along the system has

<br>evolved to accommodate them

<br>We want to keep the language constant, while adapting the run-time

system to modern architectures.

This takes priority over language changes.

<br>

<br>6) If you made a change like this and distributed the code somebody

<br>who read the code later would not

<br>know what the code meant. You can't have the same syntax for something

<br>in a program that means two different things

at two different times.

<br>

<br>7) I'm not against change as such - but we do have to take backwards

comparability seriously for many reasons.

<br>We want to improve the system, subject to the condition that we don't

<br>break the existing stuff. Even small change

<br>require a lot of work, it's not just a question of changing the parser

<br>and compiler. All third-part tools have to be changed

the dialyzer, quickcheck, eclipse IDE, refactoring tools etc.

<br>

<br>8) Erlang could do with some major changes - I proposed erl2 a while

<br>back but these changes are too

<br>dramatic to be accommodated in a incremental and backwards compatible

<br>manner. I perceive erl2 as a code generator

that produces regular erlang programs.

<br>

<br>/Joe

<br>

<br>>

<br>> On Tuesday, July 10, 2012 1:40:17 PM UTC+4, Sergei Lebedev wrote:

<br>>>

<br>>> Richard,

<br>>>

<br>>> While this indeed *may* be a sign of a problem in your code, for the

<br>>> original example this is hardly the case. Splitting the function apart

<br>>> *only* because of compiler limitations sounds like an ad-hoc hack, not a

<br>>> real solution.

<br>>>

<br>>> -- Sergei

<br>>>

<br>>> On Jul 10, 2012, at 1:02 PM, Richard Carlsson wrote:

<br>>>

<br>>> > On 07/10/2012 10:43 AM, Dmitry Groshev wrote:

<br>>> >> case do_something() of

<br>>> >>     {ok, Result} -> Result;

<br>>> >>     {error, Error} -> Error

<br>>> >> end,

<br>>> >> case do_another() of

<br>>> >>     {ok, Result} -> Result;

<br>>> >>     {error, Error} -> Error

<br>>> >> end,

<br>>> >>

<br>>> >> Result and Error are bound in first case and we will probably have a

<br>>> >> match failure in second one. Compiler warns about this, but it's still

>> >> very unwieldy to fix it with names like Error1, Error2, etc.

<br>>> >

<br>>> > Take it as a sign that you should break out those case expressions into

>> > separate functions, or restructure the code in some other way.

<br>>> >

<br>>> >    /Richard

<br>>> > ______________________________<wbr>_________________

<br>>> > erlang-questions mailing list

<br>>> > <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>

<br>>> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br>>>

<br>>> ______________________________<wbr>_________________

<br>>> erlang-questions mailing list

<br>>> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>

<br>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br>>

<br>>

<br>> On Tuesday, July 10, 2012 1:40:17 PM UTC+4, Sergei Lebedev wrote:

<br>>>

<br>>> Richard,

<br>>>

<br>>> While this indeed *may* be a sign of a problem in your code, for the

<br>>> original example this is hardly the case. Splitting the function apart

<br>>> *only* because of compiler limitations sounds like an ad-hoc hack, not a

<br>>> real solution.

<br>>>

<br>>> -- Sergei

<br>>>

<br>>> On Jul 10, 2012, at 1:02 PM, Richard Carlsson wrote:

<br>>>

<br>>> > On 07/10/2012 10:43 AM, Dmitry Groshev wrote:

<br>>> >> case do_something() of

<br>>> >>     {ok, Result} -> Result;

<br>>> >>     {error, Error} -> Error

<br>>> >> end,

<br>>> >> case do_another() of

<br>>> >>     {ok, Result} -> Result;

<br>>> >>     {error, Error} -> Error

<br>>> >> end,

<br>>> >>

<br>>> >> Result and Error are bound in first case and we will probably have a

<br>>> >> match failure in second one. Compiler warns about this, but it's still

>> >> very unwieldy to fix it with names like Error1, Error2, etc.

<br>>> >

<br>>> > Take it as a sign that you should break out those case expressions into

>> > separate functions, or restructure the code in some other way.

<br>>> >

<br>>> >    /Richard

<br>>> > ______________________________<wbr>_________________

<br>>> > erlang-questions mailing list

<br>>> > <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>

<br>>> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br>>>

<br>>> ______________________________<wbr>_________________

<br>>> erlang-questions mailing list

<br>>> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>

<br>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br>>

<br>>

<br>> ______________________________<wbr>_________________

<br>> erlang-questions mailing list

<br>> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>

<br>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br>>

<br>______________________________<wbr>_________________

<br>erlang-questions mailing list

<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>

<br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a>

<br></blockquote>