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

[Eric Pailleau]

+1

Envoyé depuis mon mobile 

---- Stanislav Ledenev a écrit ----

>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 wont
>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.
>
>пт, 29 апр. 2022 г. в 09:33, Chris Rempel <csrl@REDACTED>:
>
>> 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.
>>
>> 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.
>>
>> Regards,
>> Chris
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220429/e878a640/attachment.htm>