<div dir="ltr"><div>Hi</div><div><br></div><div>not wanting to convince anyone, just taking part in the opinion poll</div><div>I certainly hit the issue myself accidentally reusing a variable as well as not spotting when reviewing code, and I would be fine to use the new pin notation.</div><div>IDE support would help although it does not reflect the author's intent.</div><div><br></div><div>Only slightly related, got hit by the below using ms_transform in files</div><div><br></div><div>f1(Table, BoundKey) -><br>    ets:select(Table, ets:fun2ms(fun({Key, Value}) when Key =:= BoundKey -> Value end)).</div><div><br></div><div>f2(Table, BoundKey) -><br>    ets:select(Table, ets:fun2ms(fun({BoundKey, Value})  -> Value end)).<br></div><div><br></div><div>The first function does a full table search while the second does a straight key lookup (at least in the shell, in file BoundKey is obviously shadowed). I find match-spec-functions much more readable but unfortunately today there is no fun representation of</div><div>[{{BoundKey, '$2'}, [], ['$2']}]</div><div>When I saw the first post of Richard, it reminded me of this issue, that the pin syntax could be used here too. Maybe this can be addressed in many other ways, the ms_transform magic or the pattern-match-interpreter could be made smarter.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 18, 2021 at 10:23 PM Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org">raimo+erlang-questions@erlang.org</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 Mon, Jan 18, 2021 at 07:22:21PM +0000, Matt Kowlaczyk wrote:<br>
> Jose Valim wrote a well written blog post titled "Comparing Elixir and<br>
> Erlang variables" [1] where he highlights the pin operator in Elixir and<br>
> explorers some of it's benefits. He succinctly addresses the class of<br>
> bugs of it catches and contrasts the operator with Erlang. Here is a<br>
> short snippet,<br>
> <br>
> > In other words, so far Elixir requires you to be mindful of all later<br>
> > code after the introduction of a variable while Erlang requires you to<br>
> > know all previous and further code before the introduction of a<br>
> > variable. The one benefit of Erlang so far is that the code may crash<br>
> > explicitly on the match.<br>
> ><br>
> > However, things get more complicated when considering case expressions.<br>
> ><br>
> Thought this would provide some useful context. It would be interesting<br>
> to see how the ideas in Jose's post reconcile under this proposed EEP. I<br>
> have not gone through the exercise.<br>
> <br>
> [1]<br>
> <a href="http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-variables/" rel="noreferrer" target="_blank">http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-variables/</a><br>
<br>
As I read that blog post, most problems with the Erlang semantics that José<br>
lists would be remedied, if Erlang should have had a mandatory syntax for<br>
matching a variable.<br>
<br>
Most, but not for the problems with "Numbered variables", because Erlang<br>
does not have rebinding of variables.<br>
<br>
> <br>
> <br>
> -- <br>
> Matt Kowalczyk<br>
> <br>
<br>
-- <br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
</blockquote></div>