<p dir="ltr" style="margin-top:0; margin-bottom:0;">+1</p>
<br>
<p dir="ltr" style="margin-top:0; margin-bottom:0;">Envoyé depuis mon mobile </p><br><br>---- Stanislav Ledenev a écrit ----<br><br><div dir="ltr">Further we go, the worse it becomes. Erlang's community 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's take a look at this stupid operator ^.<br>What do we know about it?<br>1. It is optional;<br>2. This operator should clearly state that the variable is already bound.<br><br>Don'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't need this operator.<br><br>Ok. But this operator is for humans! Those wonderful people would read a code<br>and they get their "a-ha" moment when they'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 or accidentally. NOTHING. No punishment.<br>Why should I bother then?<br><br>This particular EEP's "problem" can be solved like this:<br>f(X, Y) -><br>    case X of<br>        {a, Y} -> ok; % Y is already bound<br>        _ -> error<br>    end.<br>    <br>See - no changes to the compiler. Right out of the hat.<br><br>I've seen here about the annotations as another "solution". Hell, no. Look at<br>Java's annotations. You never know what the hell is going on behind this annotation<br>without source code examination. <br><br>Erlang's source code has always been so perfectly clear. Erlang's syntax is brilliantly, <br>geniously simple! I've never had any problems reading any of Erlang's code - servers, clients,<br>cryptography, OTP itself, e.t.c.  Of course you must be aware of the domain problem.<br><br>So what is this all about? It's all about the community on the path of inventing<br>problems and defeating these imaginary problems. Defending from extraterrestrials.<br>Grief from mind.<br><br>Please stop it.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 29 апр. 2022 г. в 09:33, Chris Rempel <<a href="mailto:csrl@gmx.com">csrl@gmx.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><div style="font-family:Verdana;font-size:12px"><div>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 variable shadowing, then all that remains is subjective readability which can be addressed with generic annotations or tooling (syntax highlighting, linting etc).  Other scoping improvements can be made as well. The pinning operator opens the door for rebinding variables at a later date.  And that is a fundamental language change.</div>

<div> </div>

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

<div> </div>

<div>Regards,</div>

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