<div dir="ltr"><div>Hi,</div><div><br></div><div>I have written a lot of code where the function clauses used having the same variable twice a lot. Like, really a lot.</div><div><br></div><div>f(X, X) -> ...</div><div><br></div><div>This would be a real bummer to lose.</div><div>It makes a lot of code really concise because you push the first decision to the front of your function clauses.</div><div><br></div><div>Elixir allows the same, so nothing lost on that front.</div><div><br></div><div>That said, I am rarely using an already bound variable in a match.</div><div>The only place it may come up is in a case-statement, but still, very rare.</div><div>I - like other comments in this thread - favour small function bodies, where the need for re-assignment to a variable is a lot smaller and the need for matching on an already bound variable is equally small, if not done in the function head.</div><div><br></div><div>Erlang has, IMO, the advantage that if you've bound a variable you cannot change it. That is simple to grasp.</div><div>In Elixir you can write</div><div style="margin-left:40px"><span style="font-family:monospace">def funky(x, x) do</span></div><div style="margin-left:40px"><span style="font-family:monospace">  x = x + 42</span></div><div style="margin-left:40px"><span style="font-family:monospace">  x</span></div><div style="margin-left:40px"><span style="font-family:monospace">end</span></div><div><br></div><div>That takes a bit more explaining, which is the downside of abandoning of single assignment.</div><div>I can live with this in Elixir because I use the same coding style (small function bodies), so the need for this is small in my code.</div><div><br></div><div>There are times where I miss Pascal's assignment: x := 42 means that you are giving x a new value and x = 42 means comparison.</div><div>I haven't coded Pascal in anger for ~30 years so it may be that my memory is kinder to this construct than it ought to be.</div><div><br></div><div>At the end of the day I am happy with the way single assignment is implemented in Erlang, so I would be slightly annoyed by the proposed change, but I would be downright angry if reusing the same variable in the head of a function clause was changed.</div><div><br></div><div>Cheers,</div><div>Torben<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 17 Jan 2021 at 13:45, Richard O'Keefe <<a href="mailto:raoknz@gmail.com">raoknz@gmail.com</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"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Am I the only one who finds the word "pinning"</div><div class="gmail_default" style="font-family:monospace,monospace">confusing?  I know what "pinning a bone" means.</div><div class="gmail_default" style="font-family:monospace,monospace">I know what "pinning an insect to a board"</div><div class="gmail_default" style="font-family:monospace,monospace">means.  I know what "pinning an enemy/opponent"</div><div class="gmail_default" style="font-family:monospace,monospace">means in war, wrestling, or chess. I am not an</div><div class="gmail_default" style="font-family:monospace,monospace">Elixir programmer (the syntax has always struck</div><div class="gmail_default" style="font-family:monospace,monospace">me as, um, more pain than whatever other gain I</div><div class="gmail_default" style="font-family:monospace,monospace">might get from Elixir), so I don't know what</div><div class="gmail_default" style="font-family:monospace,monospace">"to pin" means in Elixir. <br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I am also confused by it being called an operator.</div><div class="gmail_default" style="font-family:monospace,monospace">It appears to be an ANNOTATION, not an operator,</div><div class="gmail_default" style="font-family:monospace,monospace">some sort of "hey I really meant to have an</div><div class="gmail_default" style="font-family:monospace,monospace">already bound variable here" annotation.  It</div><div class="gmail_default" style="font-family:monospace,monospace">certainly doesn't *act* like an operator.</div><div class="gmail_default" style="font-family:monospace,monospace">If it were an operator, I'd be asking what ^X+1</div><div class="gmail_default" style="font-family:monospace,monospace">meant and what ^1+X meant.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Since Erlang has two notions of equality, I</div><div class="gmail_default" style="font-family:monospace,monospace">would be much happier with an optional style</div><div class="gmail_default" style="font-family:monospace,monospace">rule that says "all variables in a pattern</div><div class="gmail_default" style="font-family:monospace,monospace">must be new" (like patterns in Haskell, SML,</div><div class="gmail_default" style="font-family:monospace,monospace">and so on) forcing you to show in the guard</div><div class="gmail_default" style="font-family:monospace,monospace">which version of equality you wanted.  This</div><div class="gmail_default" style="font-family:monospace,monospace">would be a pure restriction on existing</div><div class="gmail_default" style="font-family:monospace,monospace">Erlang syntax; any code accepted under this</div><div class="gmail_default" style="font-family:monospace,monospace">rule would also be acceptable under unrestricted</div><div class="gmail_default" style="font-family:monospace,monospace">Erlang and would have the same meaning.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I note that none of the other functional</div><div class="gmail_default" style="font-family:monospace,monospace">languages I use (Haskell, SML, OCaml, F#)</div><div class="gmail_default" style="font-family:monospace,monospace">have any analogue of ^X and they don't need</div><div class="gmail_default" style="font-family:monospace,monospace">it.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 17 Jan 2021 at 21:18, Valentin Micic <<a href="mailto:v@micic.co.za" target="_blank">v@micic.co.za</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"><br>
> On 15 Jan 2021, at 17:35, Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org" target="_blank">raimo+erlang-questions@erlang.org</a>> wrote:<br>
> <br>
…<br>
<br>
> 1) Would the language be a better language with a mandatory pinning operator?<br>
> <br>
> <br>
<br>
<br>
I think this must always be our starting point.<br>
Without asking this question, we might wake up one day programming in C++ (not that anything is wrong with that… well, other than esoteric syntax).<br>
<br>
V/<br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a href="http://www.linkedin.com/in/torbenhoffmann" target="_blank">http://www.linkedin.com/in/torbenhoffmann</a><br></div>@LeHoff<br></div></div>