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

Stanislav Ledenev s.ledenev@REDACTED
Fri Apr 29 10:46:40 CEST 2022


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/2de7c66a/attachment.htm>


More information about the erlang-questions mailing list