Re: [Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
"Richard O'Keefe" <[email protected]> Fri, 29 Apr 2022 23:44:58 +1200
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CABcYAdLMwD1otKSeKOrZ_VzfqwjfLiJnVWKQmt5r9PT8W=5fPA@mail.gmail.com> |
--00000000000037497c05ddc99363 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I should make it clear that my "counter-proposal" is meant to demonstrate that the possible solution space relevant to the EEP has NOT BEEN ADEQUATELY EXPLORED YET. If it were fully worked out, the counter-proposal would be an EEP itself. I'm not saying "there is no problem" or "let's never do anything new" or "Erlang is perfect". (I've written a lot of EEPs myself.) I'm saying something that should be fairly easy to accept: *this* EEP is nowhere near ready for acceptance. Frames were an EEP, and we got maps instead (which I am still miffed about, but everyone else seems to be very happy). And we got them a long time after a fairly detailed Frames design was provided, because the maintainers wanted one mechanism that solved two different things, not the one thing that Frames were designed for. For what it's worth, I had a three-part proposal for adding something very like assignment to Erlang, starting with X :=3D e handled by renaming, and proceeding to assignment of substructures using lenses. I never got around to writing it all up, because honestly, there are just better ways to write Erlang than the ways that would have been helped with this. And I can tell you that the "pinning" operator would not have been useful for this at all, but on the contrary, a major pain to deal with. No, an EEP that was never submitted is not a good reason to reject an EEP that *was*. All it can be is a reminder that the space of possible solutions should never be constrained to "what the cool kids are using". On Fri, 29 Apr 2022 at 21:48, Lo=C3=AFc Hoguin <[email protected]> wrote: > On 28/04/2022 14:00, Richard O'Keefe wrote: > > (A) Fix the original problem. Erlang had a very > > simple scope rule: the scope of a variable is > > the *entire* top-level function clause it > > occurs in. Reinstate that rule. > > This is a breaking change, so it needs some > > sort of -simple_scopes declaration to enable it. > > We now have a feature declaration that can be > > used for this. > > This is the solution I would prefer with regard to solving locality and > shadowing. But I am well aware that this would not solve the original > issue, in particular it wouldn't help avoid accidental matching of > variables that were already bound. What's at the beginning of the > rationale. > > There would still need to be a compiler warning/error (should really be > an error if not already) about exporting variable from case clauses > where the variable is not defined in all clauses, though, but that's fine= . > > > (B) Fix the locality problem. The right way. > > By declaring which variables are *local*, > > not which variables are *not* local. > > Borrowing some syntax from Prolog (as Erlang > > originally got its syntax thence), let D be > > a syntactic form made of tuples, lists, and > > variables, and C be a pattern or expression. > > Then D ^ C means that each of the variables > > in D represents a new variable in C, not > > provided, visible, or in any way accessible > > in C. > > This would also be acceptable but I too would like to see what it would > look like. I fear that it may end up much more complex to the developer > than the first solution. Also it probably doesn't solve the original > issue in the rationale. > > -- > Lo=C3=AFc Hoguin > https://ninenines.eu > --00000000000037497c05ddc99363 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac= e,monospace">I should make it clear that my "counter-proposal" is= </div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace= ">meant to demonstrate that the possible solution space</div><div class=3D"= gmail_default" style=3D"font-family:monospace,monospace">relevant to the EE= P has NOT BEEN ADEQUATELY EXPLORED YET.</div><div class=3D"gmail_default" s= tyle=3D"font-family:monospace,monospace">If it were fully worked out, the c= ounter-proposal would</div><div class=3D"gmail_default" style=3D"font-famil= y:monospace,monospace">be an EEP itself.</div><div><br></div><div><span cla= ss=3D"gmail_default" style=3D"font-family:monospace,monospace">I'm not = saying "there is no problem" or "let's never do</span></= div><div><span class=3D"gmail_default" style=3D"font-family:monospace,monos= pace">anything new" or "Erlang is perfect".=C2=A0 (I've = written a</span></div><div><span class=3D"gmail_default" style=3D"font-fami= ly:monospace,monospace">lot of EEPs myself.)</span></div><div><span class= =3D"gmail_default" style=3D"font-family:monospace,monospace"><br></span></d= iv><div><span class=3D"gmail_default" style=3D"font-family:monospace,monosp= ace">I'm saying something that should be fairly easy to</span></div><di= v><span class=3D"gmail_default" style=3D"font-family:monospace,monospace">a= ccept: *this* EEP is nowhere near ready for acceptance.</span></div><div><s= pan class=3D"gmail_default" style=3D"font-family:monospace,monospace">Frame= s were an EEP, and we got maps instead (which I am</span></div><div><span c= lass=3D"gmail_default" style=3D"font-family:monospace,monospace">still miff= ed about, but everyone else seems to be very</span></div><div><span class= =3D"gmail_default" style=3D"font-family:monospace,monospace">happy).=C2=A0 = And we got them a long time after a fairly</span></div><div><span class=3D"= gmail_default" style=3D"font-family:monospace,monospace">detailed Frames de= sign was provided, because the maintainers</span></div><div><span class=3D"= gmail_default" style=3D"font-family:monospace,monospace">wanted one mechani= sm that solved two different things, not</span></div><div><span class=3D"gm= ail_default" style=3D"font-family:monospace,monospace">the one thing that F= rames were designed for.</span></div><div><span class=3D"gmail_default" sty= le=3D"font-family:monospace,monospace"><br></span></div><div><span class=3D= "gmail_default" style=3D"font-family:monospace,monospace">For what it's= worth, I had a three-part proposal for</span></div><div><span class=3D"gma= il_default" style=3D"font-family:monospace,monospace">adding something very= like assignment to Erlang, starting</span></div><div><span class=3D"gmail_= default" style=3D"font-family:monospace,monospace">with X :=3D e handled by= renaming, and proceeding to</span></div><div><span class=3D"gmail_default"= style=3D"font-family:monospace,monospace">assignment of substructures usin= g lenses.=C2=A0 I never got</span></div><div><span class=3D"gmail_default" = style=3D"font-family:monospace,monospace">around to writing it all up, beca= use honestly, there are</span></div><div><span class=3D"gmail_default" styl= e=3D"font-family:monospace,monospace">just better ways to write Erlang than= the ways that would</span></div><div><span class=3D"gmail_default" style= =3D"font-family:monospace,monospace">have been helped with this.=C2=A0 And = I can tell you that the</span></div><div><span class=3D"gmail_default" styl= e=3D"font-family:monospace,monospace">"pinning" operator would no= t have been useful for this at</span></div><div><span class=3D"gmail_defaul= t" style=3D"font-family:monospace,monospace">all, but on the contrary, a ma= jor pain to deal with.</span></div><div><span class=3D"gmail_default" style= =3D"font-family:monospace,monospace">No, an EEP that was never submitted is= not a good reason</span></div><div><span class=3D"gmail_default" style=3D"= font-family:monospace,monospace">to reject an EEP that *was*.=C2=A0 All it = can be is a reminder</span></div><div><span class=3D"gmail_default" style= =3D"font-family:monospace,monospace">that the space of possible solutions s= hould never be</span></div><div><span class=3D"gmail_default" style=3D"font= -family:monospace,monospace">constrained to "what the cool kids are us= ing".</span></div><div><span class=3D"gmail_default" style=3D"font-fam= ily:monospace,monospace"><br></span></div><div><span class=3D"gmail_default= " style=3D"font-family:monospace,monospace"><br></span></div><div><span cla= ss=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></span><= /div><div><span class=3D"gmail_default" style=3D"font-family:monospace,mono= space"></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c= lass=3D"gmail_attr">On Fri, 29 Apr 2022 at 21:48, Lo=C3=AFc Hoguin <<a h= ref=3D"mailto:[email protected]">[email protected]</a>> wrote:<br></di= v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= r-left:1px solid rgb(204,204,204);padding-left:1ex">On 28/04/2022 14:00, Ri= chard O'Keefe wrote:<br> > (A) Fix the original problem.=C2=A0 Erlang had a very<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 simple scope rule: the scope of a variable is= <br> >=C2=A0 =C2=A0=C2=A0=C2=A0 the *entire* top-level function clause it<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 occurs in.=C2=A0 Reinstate that rule.<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 This is a breaking change, so it needs some<b= r> >=C2=A0 =C2=A0=C2=A0=C2=A0 sort of -simple_scopes declaration to enable = it.<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 We now have a feature declaration that can be= <br> >=C2=A0 =C2=A0=C2=A0=C2=A0 used for this.<br> <br> This is the solution I would prefer with regard to solving locality and <br= > shadowing. But I am well aware that this would not solve the original <br> issue, in particular it wouldn't help avoid accidental matching of <br> variables that were already bound. What's at the beginning of the ratio= nale.<br> <br> There would still need to be a compiler warning/error (should really be <br= > an error if not already) about exporting variable from case clauses <br> where the variable is not defined in all clauses, though, but that's fi= ne.<br> <br> > (B) Fix the locality problem.=C2=A0 The right way.<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 By declaring which variables are *local*,<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 not which variables are *not* local.<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 Borrowing some syntax from Prolog (as Erlang<= br> >=C2=A0 =C2=A0=C2=A0=C2=A0 originally got its syntax thence), let D be<b= r> >=C2=A0 =C2=A0=C2=A0=C2=A0 a syntactic form made of tuples, lists, and<b= r> >=C2=A0 =C2=A0=C2=A0=C2=A0 variables, and C be a pattern or expression.<= br> >=C2=A0 =C2=A0=C2=A0=C2=A0 Then D ^ C means that each of the variables<b= r> >=C2=A0 =C2=A0=C2=A0=C2=A0 in D represents a new variable in C, not<br> >=C2=A0 =C2=A0=C2=A0=C2=A0 provided, visible, or in any way accessible<b= r> >=C2=A0 =C2=A0=C2=A0=C2=A0 in C.<br> <br> This would also be acceptable but I too would like to see what it would <br= > look like. I fear that it may end up much more complex to the developer <br= > than the first solution. Also it probably doesn't solve the original <b= r> issue in the rationale.<br> <br> -- <br> Lo=C3=AFc Hoguin<br> <a href=3D"https://ninenines.eu" rel=3D"noreferrer" target=3D"_blank">https= ://ninenines.eu</a><br> </blockquote></div> --00000000000037497c05ddc99363--