<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Wed, Jan 20, 2021 at 1:47 AM Chris Rempel <<a href="mailto:csrl@gmx.com">csrl@gmx.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
yet today we can already write:<br>
<br>
f (X, Y) -><br>
  case X of<br>
    {a, Y2} when Y2 =:= Y -> {ok ,Y2};<br>
    _ -> error<br>
  end.<br>
<br>
So, for those who want this EEP in order to be more explicit, why do you not<br>
write your code in that third form and introduce an EEP requesting a compiler<br>
flag that you can use to generate a warning in the first form above, so that<br>
you rewrite it in the third form. The second form flies in the face of how I,<br>
and apparently many others, think in Erlang. The pinning operator is<br>
extraneous, and in fact determintal to that way of thinking.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">This one has a valid concern. When you start numbering your variables, you also introduce an order on them in code. As you manipulate code in an editor, these numbers tend to require frequent updates. Even if you want the numbers, having the pinning ability as an interim would help. The ability to (recursively) rebind a new value to a name is the common way functional languages handle this, whereas the unification check is closer to the Prolog heritage. There are good reasons for both, but one should definitely have a way to turn the Prolog variant into the FP variant. FWIW, I've always found the rebinding to be the preferred default, since that's what I'm most often interested in doing. The Erlang variant often just breaks my code, and I'd much rather write an explicit assertion in the program if I need it.</div><br></div></div></div>