New EEP draft: Pinning operator ^ in patterns

[zxq9]

Nice reply. I'm just responding to highlight and reiterate.

On 2021/01/20 9:47, Chris Rempel wrote:
[snip]
> But in both cases, I have to explicitly say, hey Erlang, don't break your own
> rule that a variable value never changes. To me this EEP is fixing the problem
> in the wrong way.
> 
> So, if there is any proposal to put forth, in my view, it is to get rid of
> variable shadowing.

100% this.

> Also, already in this thread it is now being mentioned to have variable
> rebinding support. If this EEP erodes such a core tenant (in my view) of
> Erlang such that it leads to variable rebinding, it should be rejected on that
> alone (in my view).
> 
> But the part of the EEP that just completely nullifies it is:
> 
[snip]
> You now have two variables named the same thing with different values. It
> breaks fundamental way of thinking in Erlang.  There is zero value in allowing
> this. Use a different variable name.

Yes.

> So, I'd like to propose that any EEP added to https://github.com/erlang/eep/
> is done in a PR and left open for reviews/comments on the PR for a period of
> time. There is much in the EEP that I would comment on, line by line.

Nice idea. I'm not sure how much uptake it would gain over email 
responses, but sure.

> There has been concern on the list that this discussion has not remained
> technical and on point to the value of the EEP, and I would suggest the fault
> lies in the tool being used to elicit feedback (e-mail). That concern would be
> addressed by allowing people to comment line by line on the EEP and discuss
> the specific points of the EEP in the PR itself. And we can avoid blame being
> thrown around about people having or not having read the EEP.

I get the feeling that someone already has a plan and they are just 
going to shove it through no matter how stupid it is because having 
Elixir be Elixirish isn't good enough, they have to pollute Erlang, too.

Mantra: There can only be one way to do it, and it has to be wrong.

One of the more annoying things about the proposal is that it is 
impossible to actually search for if you don't already know what it is 
called, and if you do you don't need to search for it. The term "pinning 
operator" is certainly not what would come to mind since it doesn't mean 
anything that the semantics of the term hint at, and the idea that "Oh, 
I can rebind or annotatively alias stuff in Erlang, a language 
absolutely famous for having single-binding?" is rather alien and should 
remain so.

It literally isn't even an operator.
Literally.
I literally can't even. (Am I doing 2021 right?)

A second somewhat silly thing about this is the attitude of "Oh, well, 
fortunately in Erlang the '^' character was free to use so we'll just 
use it!" without considering that this will also remove it from the list 
of available characters for at least a decade even if you added it in 
the next release and removed it immediately afterward. This character 
actually *is* used as an operator in many languages and notations for 
exponentiation.

"Will this make Erlang a better language?"
No. It will make it harder to understand because people will be 
surprised when they see what looks like a random typo in the code 
because this silly convention has so few use cases.

"Will this make Erlang an easier to learn language?"
Adding flippant idiosyncrasies never makes a language easier to learn. 
Removing shadowing in funs would, though.
This is a *complication*, not a *simplification*.

-Craig