New EEP draft: Pinning operator ^ in patterns

[Coconut]

Hello. I am quite new to Erlang, but I think not being able to rebound variables (or shadowing in such a way) is one of Erlang's great features and partly what makes Erlang that; Erlang. I would rather prefer if it were not stirred up by adding this pinning operator that would most likely just make things more confusing to newcomers, and at the same time take away a great feature from Erlang.

If people want something like rebound variables or whatever pinning operator is in Elixir, and still target the Beam, they should go to Elixir, but in my opinion Erlang should be left alone as it is. Please. Do not add the pinning operator. Keep those "new" features to Elixir if anything, but I do not want Erlang to be yet another language that gets many different "features" just because. I know what the benefits may be, but I think the negatives far outweigh the positives here. When I look at the source code, I know that the variable has not been rebound. It helps A LOT, especially if I am reading someone else's code. I do not know if I would use Erlang if it was added, in all fairness.

Single assignment is a great thing. Do not mess with it in any way, please. Erlang is not Elixir, and do NOT make it become Elixir. Let me emphasize: this would be utterly confusing to newcomers, and probably even older Erlangers, and would make code much harder to follow.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 27, 2021 12:41 PM, Richard Carlsson <carlsson.richard@REDACTED> wrote:

> Den tis 19 jan. 2021 kl 13:56 skrev Karl Velicka <karolis.velicka@REDACTED>:
>
>> In addition, I feel like there's been a certain lack of forthcomingness from Richard and/or the WhatsApp team (certainly in the initial post at least) about the intent and larger picture of this change - there has been a mention in this thread about the possibility of eventually making the operator mandatory etc but none of that is in the proposal and I really think it should be. I think it may be easier to sell the community on the direction Whatsapp believes Erlang should be heading in rather than being drop-fed certain aspects/features of it in isolation.
>>
>> Lastly, I wonder if there's some "ulterior" motive here. In quotes because I don't think the motive is at all dishonest but I suspect there is one - reading between the lines, there's been a few mentions about how the current Erlang is more difficult to parse/analyse because match patterns need extra information about which variables are already bound and to what. Am I inferring correctly that this EEP also serves a simplification of the language (from the POV of a machine), which is possibly related to some internal static analysis that WhatsApp is doing/would like to do, or perhaps is related to the fabled static typed Erlang that they are said to be working on? This may well be something that the community at large be interested in!
>
> Here's another one I should have answered earlier. Although it's no secret and it's been written about in some places, I'm also sure that not everyone heard it: During 2020, a team at WhatsApp - including myself as an external consultant - was working on prototyping a "modernized Erlang", exploring various ideas for making Erlang a better language for large scale development. If there's a short way to summarize what that means, it might be "giving you faster feedback". The longer it takes to understand something, and the longer it takes for you to find out after you made a change that something is wrong, the slower development gets. Especially when you have many people working on the code and you have a large code base that is constantly being modified, this is perhaps the most important thing today for a language.
>
> The main thing that the team focused on was trying to find a model of static typing that could work in practice for real Erlang code (of which WhatsApp has a lot) - one that could give you quick feedback (even in the editor) and complete certainty that all checked parts of the code had no type errors (thus not like dialyzer). As you may also have heard already, this direction was put on ice at the end of 2020, because it seemed like it couldn't provide a transition route quickly enough. The project continues, but for now focusing on incremental improvements. But the team also looked at things like scoping, naming, modules, and data types, and is very actively contributing to the Erlang Language Server. The PR for column numbers in error messages (see https://github.com/erlang/otp/pull/3006) was also a result of this project.
>
> As the project changed direction, we thought that we should at least try to push out those ideas that seemed viable and useful as incremental changes on Erlang as it is. The pinning part seemed to be the least complicated and providing most benefit in the short term. Other things we tried with regard to scoping and naming were not as "finished", and it's harder to say exactly what the end goal should be, only that pinning would enable more uniform and predictable scoping rules no matter which direction you take next. That said, starting this year I'm only taking an advisory role for the project, and I'm doing this out of my own invested interest in Erlang.
>
> /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210127/9c9a2875/attachment.htm>