<div dir="ltr">Hi Torben! I don't have any separate analysis tools, basically just some printfs in the compiler. The easiest way to test this on your own code is to build the branch from the demo pull request: <a href="https://github.com/erlang/otp/pull/2951">https://github.com/erlang/otp/pull/2951</a> - then compile your code with +warn_unpinned_vars.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>        /Richard</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tis 19 jan. 2021 kl 14:13 skrev Torben Hoffmann <<a href="mailto:torben.lehoff@gmail.com">torben.lehoff@gmail.com</a>>:<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>Hi Richard,<br></div><div><br></div><div><div>Thanks for clarifying.</div></div><div>In that case my biggest worry is off the table - I have a lot of code that would be broken by my misinterpretation, so I'm glad I misread the discussion in this thread.</div><div><br></div><div>Given that the migration path doesn't break things nor take away from binding twice in a pattern match (my biggest beef), it boils down to whether this is a good thing to have or not.</div><div><br></div><div>I'm of the opinion that matching against an already bound variable should almost exclusively be done in a function clause header or in a case clause (as your example).</div><div>Your analysis of the OTP code base shows that this isn't used much, ie, fixing that would be a small thing.</div><div>If you could release the code to spot these usages others could run it on their own code base and be relieved that they don't have a huge body of things to update.</div><div><br></div><div>As pinning would make the intention of the code clearer I am in favour of introducing it. <br></div><div>Intention is one of the most important aspects of code maintainability and this EEP provides that at a small cost.</div><div><br></div><div>Cheers,</div><div>Torben<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Jan 2021 at 12:56, Richard Carlsson <<a href="mailto:carlsson.richard@gmail.com" target="_blank">carlsson.richard@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">There is nothing in this suggestion that affects the reuse of the same variable within a pattern.<div>If it's a new variable that's supposed to have the same value in both positions, it would look like before: "{X, X} -> ...".</div><div>If it's an already bound variable that occurs twice in the same pattern, you'd mark both instances: "{^X, ^X} -> ...".</div><div><div><div dir="ltr"></div></div></div><div><div dir="ltr"><br>        /Richard</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 18 jan. 2021 kl 08:25 skrev Torben Hoffmann <<a href="mailto:torben.lehoff@gmail.com" target="_blank">torben.lehoff@gmail.com</a>>:<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>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" target="_blank">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"><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>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><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>
</blockquote></div>