<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I should make it clear that my "counter-proposal" is</div><div class="gmail_default" style="font-family:monospace,monospace">meant to demonstrate that the possible solution space</div><div class="gmail_default" style="font-family:monospace,monospace">relevant to the EEP has NOT BEEN ADEQUATELY EXPLORED YET.</div><div class="gmail_default" style="font-family:monospace,monospace">If it were fully worked out, the counter-proposal would</div><div class="gmail_default" style="font-family:monospace,monospace">be an EEP itself.</div><div><br></div><div><span class="gmail_default" style="font-family:monospace,monospace">I'm not saying "there is no problem" or "let's never do</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">anything new" or "Erlang is perfect".  (I've written a</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">lot of EEPs myself.)</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">I'm saying something that should be fairly easy to</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">accept: *this* EEP is nowhere near ready for acceptance.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">Frames were an EEP, and we got maps instead (which I am</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">still miffed about, but everyone else seems to be very</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">happy).  And we got them a long time after a fairly</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">detailed Frames design was provided, because the maintainers</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">wanted one mechanism that solved two different things, not</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">the one thing that Frames were designed for.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">For what it's worth, I had a three-part proposal for</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">adding something very like assignment to Erlang, starting</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">with X := e handled by renaming, and proceeding to</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">assignment of substructures using lenses.  I never got</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">around to writing it all up, because honestly, there are</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">just better ways to write Erlang than the ways that would</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">have been helped with this.  And I can tell you that the</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">"pinning" operator would not have been useful for this at</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">all, but on the contrary, a major pain to deal with.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">No, an EEP that was never submitted is not a good reason</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">to reject an EEP that *was*.  All it can be is a reminder</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">that the space of possible solutions should never be</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">constrained to "what the cool kids are using".</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Apr 2022 at 21:48, Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 28/04/2022 14:00, Richard O'Keefe wrote:<br>
> (A) Fix the original problem.  Erlang had a very<br>
>      simple scope rule: the scope of a variable is<br>
>      the *entire* top-level function clause it<br>
>      occurs in.  Reinstate that rule.<br>
>      This is a breaking change, so it needs some<br>
>      sort of -simple_scopes declaration to enable it.<br>
>      We now have a feature declaration that can be<br>
>      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 rationale.<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 fine.<br>
<br>
> (B) Fix the locality problem.  The right way.<br>
>      By declaring which variables are *local*,<br>
>      not which variables are *not* local.<br>
>      Borrowing some syntax from Prolog (as Erlang<br>
>      originally got its syntax thence), let D be<br>
>      a syntactic form made of tuples, lists, and<br>
>      variables, and C be a pattern or expression.<br>
>      Then D ^ C means that each of the variables<br>
>      in D represents a new variable in C, not<br>
>      provided, visible, or in any way accessible<br>
>      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 <br>
issue in the rationale.<br>
<br>
-- <br>
Loïc Hoguin<br>
<a href="https://ninenines.eu" rel="noreferrer" target="_blank">https://ninenines.eu</a><br>
</blockquote></div>