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

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

Further we go, the worse it becomes. Erlang's community always seems to be
so reasonable. What the hell happened? The problem is not with this
particular EEP.
The problem is with the whole process of reasoning behind those EEPs being
broken.

Let's take a look at this stupid operator ^.
What do we know about it?
1. It is optional;
2. This operator should clearly state that the variable is already bound.

Don't you see any contradictions?

Does it mean that if this operator is not present then the variable is not
already bound?
No, because *the compiler* does the job and it doesn't need this operator.

Ok. But this operator is for humans! Those wonderful people would read a
code
and they get their "a-ha" moment when they'll see this beautiful operator.

Oh, wait a moment. But this operator is optional. What will happen if I won=
t
put it in my code? On purpose or accidentally. NOTHING. No punishment.
Why should I bother then?

This particular EEP's "problem" can be solved like this:
f(X, Y) ->
    case X of
        {a, Y} -> ok; % Y is already bound
        _ -> error
    end.

See - no changes to the compiler. Right out of the hat.

I've seen here about the annotations as another "solution". Hell, no. Look
at
Java's annotations. You never know what the hell is going on behind this
annotation
without source code examination.

Erlang's source code has always been so perfectly clear. Erlang's syntax is
brilliantly,
geniously simple! I've never had any problems reading any of Erlang's code
- servers, clients,
cryptography, OTP itself, e.t.c.  Of course you must be aware of the domain
problem.

So what is this all about? It's all about the community on the path of
inventing
problems and defeating these imaginary problems. Defending from
extraterrestrials.
Grief from mind.

Please stop it.

=D0=BF=D1=82, 29 =D0=B0=D0=BF=D1=80. 2022 =D0=B3. =D0=B2 09:33, Chris Rempe=
l <[email protected]>:

> As some of the more recent messages have stated, the pinning operator is
> the wrong solution to the problem.  Clearly, we need to be rid of variabl=
e
> shadowing, then all that remains is subjective readability which can be
> addressed with generic annotations or tooling (syntax highlighting, linti=
ng
> etc).  Other scoping improvements can be made as well. The pinning operat=
or
> opens the door for rebinding variables at a later date.  And that is a
> fundamental language change.
>
> This is all rehashing everything that was said the last time around.  And
> because the EEP process does not provide a mechanism for capturing feedba=
ck
> and iterating to a conclusion, this repeated discussion is not beneficial=
.
>
> Regards,
> Chris
>

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

<div dir=3D"ltr">Further we go, the worse it becomes. Erlang&#39;s communit=
y always seems to be <br>so reasonable. What the hell happened? The problem=
 is not with this particular EEP.<br>The problem is with the whole process =
of reasoning behind those EEPs being broken. <br><br>Let&#39;s take a look =
at this stupid operator ^.<br>What do we know about it?<br>1. It is optiona=
l;<br>2. This operator should clearly state that the variable is already bo=
und.<br><br>Don&#39;t you see any contradictions? <br><br>Does it mean that=
 if this operator is not present then the variable is not already bound?<br=
>No, because *the compiler* does the job and it doesn&#39;t need this opera=
tor.<br><br>Ok. But this operator is for humans! Those wonderful people wou=
ld read a code<br>and they get their &quot;a-ha&quot; moment when they&#39;=
ll see this beautiful operator.<br><br>Oh, wait a moment. But this operator=
 is optional. What will happen if I wont<br>put it in my code? On purpose o=
r accidentally. NOTHING. No punishment.<br>Why should I bother then?<br><br=
>This particular EEP&#39;s &quot;problem&quot; can be solved like this:<br>=
f(X, Y) -&gt;<br>=C2=A0 =C2=A0 case X of<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {a,=
 Y} -&gt; ok; % Y is already bound<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 _ -&gt; e=
rror<br>=C2=A0 =C2=A0 end.<br>=C2=A0 =C2=A0 <br>See - no changes to the com=
piler. Right out of the hat.<br><br>I&#39;ve seen here about the annotation=
s as another &quot;solution&quot;. Hell, no. Look at<br>Java&#39;s annotati=
ons. You never know what the hell is going on behind this annotation<br>wit=
hout source code examination. <br><br>Erlang&#39;s source code has always b=
een so perfectly clear. Erlang&#39;s syntax is brilliantly, <br>geniously s=
imple! I&#39;ve never had any problems reading any of Erlang&#39;s code - s=
ervers, clients,<br>cryptography, OTP itself, e.t.c.=C2=A0 Of course you mu=
st be aware of the domain problem.<br><br>So what is this all about? It&#39=
;s all about the community on the path of inventing<br>problems and defeati=
ng these imaginary problems. Defending from extraterrestrials.<br>Grief fro=
m mind.<br><br>Please stop it.<br></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">=D0=BF=D1=82, 29 =D0=B0=D0=BF=D1=80. 2022=
 =D0=B3. =D0=B2 09:33, Chris Rempel &lt;<a href=3D"mailto:[email protected]">csr=
[email protected]</a>&gt;:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div><div style=3D"font-family:Verdana;font-size:12px"><div>As some of t=
he more recent messages have stated, the pinning operator is the wrong solu=
tion to the problem.=C2=A0 Clearly, we need to be rid of variable shadowing=
, then all that remains is subjective readability which can be addressed wi=
th generic annotations or tooling (syntax highlighting, linting etc).=C2=A0=
 Other scoping improvements can be made as well. The pinning operator opens=
 the door for rebinding variables at a later date.=C2=A0 And that is a fund=
amental language change.</div>

<div>=C2=A0</div>

<div>This is all rehashing everything that was said the last time around.=
=C2=A0 And because the EEP process does not provide a mechanism for capturi=
ng feedback and iterating to a conclusion, this repeated discussion is not =
beneficial.</div>

<div>=C2=A0</div>

<div>Regards,</div>

<div>Chris</div></div></div>
</blockquote></div>

--0000000000005f26c705ddc71535--