<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>+1</p>
<p>So many good reasons were given not to introduce the pinning
operator before in this list. Very worrying!</p>
<p>Regards,<br>
</p>
<p>Frans<br>
</p>
<div class="moz-cite-prefix">On 1/14/21 3:50 PM, A. G. Madi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA06H2PoqTCMjD3DeKS3_=kGJoe0JVnNsBU2VfOeDdjk1PH0ig@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">I completely agree with Nicolas. This makes me
very nervous. </div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 14, 2021 at
08:41 Nicolas Martyanoff <<a
href="mailto:khaelin@gmail.com" moz-do-not-send="true">khaelin@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
2021-01-14 14:13, Richard Carlsson wrote:<br>
> The way I planned it is:<br>
> 1. Even from the start, pinning will always be
allowed, without requiring<br>
> any flag to opt in. This does not tell you about
existing uses of<br>
> already-bound variables, but you can start using
pinning right away for<br>
> readability and for avoiding bugs when refactoring. The
compiler will<br>
> always tell you if a pinned variable doesn't exist, so
you don't<br>
> accidentally accept any value in that position.<br>
> 2. You can enable warnings at your own pace in order
to start cleaning up<br>
> your code.<br>
> 3. In a following major release, the warnings will be
on by default, but<br>
> you can disable them to compile old code.<br>
> 4. In a distant future, it might become an error to
not use ^ to mark<br>
> already-bound variables.<br>
<br>
After reading this thread, I must say this proposal makes me
uneasy. One of<br>
the things I always liked with Erlang is the simplicity and
clarity of its<br>
syntax. Matching variables by name is perfectly readable to
me, and I never<br>
had any problem of the sort refactoring code. Adding a new
operator adds <br>
noise and transforms something simple (using the same name
to refer to the<br>
same value) into something cryptic.<br>
<br>
The fact that you envision a future where not using the
operator would signal <br>
an error is even more worrisome. I have nothing against
improving the core<br>
parts of the language (maps were a life changer for
example), but this kind of<br>
change feels really foreign to the simplicity of the Erlang
syntax.<br>
<br>
And at the risk of sounding too harsh, I would add that
while I do not mind the<br>
existence of Elixir (quite the opposite, it brought a lot of
fresh air to the<br>
entire BEAM ecosystem), I would really like Erlang to remain
Erlang; in that <br>
spirit, I see a new operator to "annotate" a perfectly clear
and working <br>
syntax as useless.<br>
<br>
Regards,<br>
<br>
-- <br>
Nicolas Martyanoff<br>
<a href="http://snowsyn.net" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://snowsyn.net</a><br>
<a href="mailto:khaelin@gmail.com" target="_blank"
moz-do-not-send="true">khaelin@gmail.com</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>