Robert, language *is* schizophrenic right now thanks to list comprehensions. <br><br>[A || {ok, A} <- B] %% there is no A outside this LC<br>case hd(B) of<br>    {ok, A} -> A<br>end<br>%% and now we have A bound. Feels like asylum<br><br>In my opinion, there are only two ways to make it less so:<br>-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;<br>-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.<br>The second one is better, I think.<br><br>On Sunday, July 15, 2012 5:01:39 AM UTC+4, Robert Virding wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">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.<p>Go Joe! I agree with what you and both Richards have written. Just some personal comments:</p><p>- 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.</p><p>- 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?</p><p>- 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.</p><p>- As has been pointed out it is not a compiler problem, having scopes is actually easier.</p><p>Robert</p><p>----- Original Message -----<br>> On Tue, Jul 10, 2012 at 12:00 PM, Dmitry Groshev<br>> <<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<br>> > the code<br>> > with nonsensical functions just to get something let-like -- AFAIK,<br>> > every<br>> > functional language out there has a local namespace for such<br>> > constructs.<br>> > Moreover, there is a huge inconsistency right now with list<br>> > comprehensions<br>> > that have their own namespace because of their transformation to<br>> > 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:<br>> > we have<br>> > an amazing BEAM, some brilliant libraries, a lot of godlike<br>> > developers, but<br>> > Erlang as a language evolves extremely slow. One reason that I can<br>> > think<br>> > about is a lack of ultimate authority that can decide what is right<br>> > and what<br>> > is wrong — theoretically there is a EEP process (and some proposals<br>> > are out<br>> > of EEPs scope, like an e2 thing), but in practice some EEPs are<br>> > here for<br>> > years (like Frames proposal or JSON BIFs) and nothing really moves<br>> > on.<br>> <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<br>>       done)<br>>       - voluntary effort (individuals make changes, which are then<br>>       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<br>> 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<br>> books in the pipeline.<br>> Lack of good documentation is probably our single greatest problem,<br>> so<br>> we don't like changes that<br>> invalidate all old documents.<br>> <br>> 4) Something like frames and JSON bifs is being implemented and will<br>> be released<br>> as soon as it is stable. And yes there is slow progress on things<br>> that are<br>> not financed. The priorities for development are set by the people<br>> who<br>> pay for the development.<br>> This means in practice that stuff that is need for Ericsson products<br>> 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<br>> but<br>> 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<br>> system to modern architectures.<br>> 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<br>> something<br>> in a program that means two different things<br>> at two different times.<br>> <br>> 7) I'm not against change as such - but we do have to take backwards<br>> 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<br>> parser<br>> and compiler. All third-part tools have to be changed<br>> 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<br>> 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<br>> >> the<br>> >> original example this is hardly the case. Splitting the function<br>> >> apart<br>> >> *only* because of compiler limitations sounds like an ad-hoc hack,<br>> >> 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<br>> >> >> have a<br>> >> >> match failure in second one. Compiler warns about this, but<br>> >> >> it's still<br>> >> >> 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<br>> >> > expressions into<br>> >> > 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<br>> >> the<br>> >> original example this is hardly the case. Splitting the function<br>> >> apart<br>> >> *only* because of compiler limitations sounds like an ad-hoc hack,<br>> >> 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<br>> >> >> have a<br>> >> >> match failure in second one. Compiler warns about this, but<br>> >> >> it's still<br>> >> >> 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<br>> >> > expressions into<br>> >> > 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>> <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></p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote>