New EEP draft: Pinning operator ^ in patterns

[Raimo Niskanen]

Hello Coconut!  Welcome to the list!

I will try to answer your questions inline below.

On Wed, Jan 27, 2021 at 05:04:21PM +0000, Coconut wrote:
> 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.

I also like that variables are only bound once, and can not really see any
future where that would change.  That would go very much against the geist
of Erlang.

So have no fear, the pinning operator would not take away any feature from
Erlang.  Hopefully it would give clarification to newcomers; when I first
learned Erlang I missed some way to see the difference between binding a
variable in a pattern and using an already bound variable.

The pinning operator would make this distinction clear, in precisely
the spot where the already bound variable is used in a pattern, which is
the odd case that deserves highlighting.

> 
> 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.

The pinning operator in Elixir is the same yet different as the one
proposed.  Adding this suggested pinning operator to Erlang would not make
it even near Elixir's variable semantics.  It just highlights something
already present in Erlang that now is done automatically and hidden.

Erlang has been and is very conservative about adding features, so
something like this will not be introduced unless it brings something
really useful, and it would be introduced in a backwards compatible way.

What are the negative sides of this proposed pinning operator that you fear
so much?  Again, it is not about rebinding variables.

> 
> 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.

Single assignment _is_ a great thing.  In what way does this pinning
operator mess with it, according to you.

Should the pinning operator be added to the language, it would not be to
bring it closer to Elixir, it would be to clarify the difference between
binding and using a bound variable in a pattern.  It resembles somewhat
what the same operator does in Elixir, but that is all.

In what way do you think it would be confusing to programmers, and why
do you think the code would be much harder to follow?

Best regards
/ Raimo Niskanen


> 
> ‐‐‐‐‐‐‐ 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

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB