Re: [Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

--0000000000007b0ab505ddae03fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Would it provide a solution to just assume that the variable shadowing is
never wanted?

What if code like:
    f(X) -> fun(X) -> X end.
    g(Y) -> case h() of Y -> %code% end.

1. Could create an error due to X being shadowed.
2. Could compile with inner X shadowed but a guard is added by the Erlang
compiler, comparing inner to the outer:
    f(X) -> fun(X2) when X2 =3D:=3D X -> X2 end.
    g(Y) -> case h() of Y2 when Y2 =3D:=3D Y -> %code% end.
3. Current behaviour: Inner X is shadowed and is an entirely new variable
(leads to naming and scoping confusion)

Solution 2 does not introduce new syntax and matches expectations for many
developers. The compiler fixes the confusion during the compile time. Also
should not break the existing code.

On Wed, 27 Apr 2022 at 21:11, Attila Rajmund Nohl <[email protected]>
wrote:

> Fred Dushin <[email protected]> ezt =C3=ADrta (id=C5=91pont: 2022. =C3=A1pr=
. 27., Sze,
> 15:14):
> >
> [...]
> > But as noted later in the EEP, this can be written as
> >
> > f(X, Y) ->
> >     F =3D fun ({a, Z}) when Z =3D:=3D Y  -> {ok, Y};
> >             (_) -> error
> >         end,
> >     F(X).
> [...]
> > And not to be too critical, but I am having a hard time understanding
> parts of the Rationale section.  The author(s) suggest(s) that in current
> Erlang temporary variables are needed to achieve the same as the proposed
> glyph, but then provide an example that uses a guard (as above) but doesn=
't
> use a temporary variable, after all (?)
>
> Z is the temporary variable in the above example.
>
> > I am not sure what the problem is with temporary variables.  The
> compiler has registers at its disposal, so I don't think it's a performan=
ce
> argument, but more an issue of readability, which again, I think is a
> purely aesthetic question, and has no bearing on the features of the
> language, per se.  In other words, the proposal is not suggesting anythin=
g
> that cannot already be achieved in current Erlang, with effectively the
> same compiled BEAM ASM.
>
> Naming is hard, and if you have to come up with two meaningful
> variable names instead of one, it's even harder. This leads to code
> like this:
>
>      F =3D fun ({a, TmpMeaningfulName}) when TmpMeaningfulName =3D:=3D
> MeaningfulName  -> {ok, MeaningfulName};
>
> The current solution in the language easily leads to too long lines or
> overly verbose code.
>

--0000000000007b0ab505ddae03fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Would=20
it provide a solution

to just assume that the variable shadowing is never wanted?</div><div><br><=
/div><div>What if code like:<br></div><div>=C2=A0=C2=A0=C2=A0 f(X) -&gt; fu=
n(X) -&gt; X end.</div><div>=C2=A0=C2=A0=C2=A0 g(Y) -&gt; case h() of Y -&g=
t; %code% end.<br></div><div><br></div><div>1. Could create an error due to=
 X being shadowed.</div><div>2. Could compile with inner X shadowed but a g=
uard is added by the Erlang compiler, comparing inner to the outer:</div><d=
iv>=C2=A0=C2=A0=C2=A0 f(X) -&gt; fun(X2) when X2 =3D:=3D X -&gt; X2 end.</d=
iv><div>=C2=A0=C2=A0=C2=A0 g(Y) -&gt; case h() of Y2 when Y2 =3D:=3D Y -&gt=
; %code% end.</div><div></div>3. Current behaviour: Inner X is shadowed and=
 is an entirely new variable (leads to naming and scoping confusion)<div><b=
r></div><div>Solution 2 does not introduce new syntax and matches expectati=
ons for many developers. The compiler fixes the confusion during the compil=
e time. Also should not break the existing code.<br></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 27 Apr 20=
22 at 21:11, Attila Rajmund Nohl &lt;<a href=3D"mailto:attila.r.nohl@gmail.=
com">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Fred Dushin &lt;<a href=3D"mailto:[email protected]=
et" target=3D"_blank">[email protected]</a>&gt; ezt =C3=ADrta (id=C5=91pont: =
2022. =C3=A1pr. 27., Sze, 15:14):<br>
&gt;<br>
[...]<br>
&gt; But as noted later in the EEP, this can be written as<br>
&gt;<br>
&gt; f(X, Y) -&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0F =3D fun ({a, Z}) when Z =3D:=3D Y=C2=A0 -&gt; {ok=
, Y};<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(_) -&gt; error<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end,<br>
&gt;=C2=A0 =C2=A0 =C2=A0F(X).<br>
[...]<br>
&gt; And not to be too critical, but I am having a hard time understanding =
parts of the Rationale section.=C2=A0 The author(s) suggest(s) that in curr=
ent Erlang temporary variables are needed to achieve the same as the propos=
ed glyph, but then provide an example that uses a guard (as above) but does=
n&#39;t use a temporary variable, after all (?)<br>
<br>
Z is the temporary variable in the above example.<br>
<br>
&gt; I am not sure what the problem is with temporary variables.=C2=A0 The =
compiler has registers at its disposal, so I don&#39;t think it&#39;s a per=
formance argument, but more an issue of readability, which again, I think i=
s a purely aesthetic question, and has no bearing on the features of the la=
nguage, per se.=C2=A0 In other words, the proposal is not suggesting anythi=
ng that cannot already be achieved in current Erlang, with effectively the =
same compiled BEAM ASM.<br>
<br>
Naming is hard, and if you have to come up with two meaningful<br>
variable names instead of one, it&#39;s even harder. This leads to code<br>
like this:<br>
<br>
=C2=A0 =C2=A0 =C2=A0F =3D fun ({a, TmpMeaningfulName}) when TmpMeaningfulNa=
me =3D:=3D<br>
MeaningfulName=C2=A0 -&gt; {ok, MeaningfulName};<br>
<br>
The current solution in the language easily leads to too long lines or<br>
overly verbose code.<br>
</blockquote></div>

--0000000000007b0ab505ddae03fa--