[erlang-questions] Local namespaces in case/try

[Dmitry Groshev]

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:
>
> 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 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120715/49687b88/attachment.htm>