New EEP draft: Pinning operator ^ in patterns

[Loïc Hoguin]

On 28/01/2021 10:57, zxq9 wrote:
> On 2021/01/28 18:25, Richard Carlsson wrote:
>> Den tors 28 jan. 2021 kl 07:19 skrev Nicolas Martyanoff 
>> <khaelin@REDACTED <mailto:khaelin@REDACTED>>:
>>
>>     I really wish people who want to see a language go a different way
>>     just create
>>     a new language of their own instead of messing with what exists and
>>     is liked
>>     as it is. José Valim did it successfully with Elixir, so yes it is
>>     possible.
>>
>>
>> If the people who rely on Erlang for their businesses and their jobs 
>> have needs that are not fulfilled by the language as it is, then 
>> either the language can evolve or those users will eventually move to 
>> another language, either on Beam or on some other platform, leaving 
>> Erlang in the eternal maintenance realm of Cobol, with no new systems 
>> being written in it, and no new users apart from those dragged in to 
>> keep some old system running. Would you prefer that? If Ericsson and 
>> others found a way to transition to Elixir, for example, would anyone 
>> keep paying for maintenance of Erlang? At least Cobol has a lot of 
>> money behind it still. If evolution is possible, then it is always 
>> preferable to creating a competing dialect.
> 
> Changes that move directly against one of the most basic core concepts 
> of the language are not only a disservice to existing codebases written 
> with those core concepts in mind, but also leaves homeless users who are 
> attracted to Erlang specifically because of those core concepts.

The result of this battle will not fundamentally change Erlang. This is 
just yet another experiment, like packages or parameterized modules 
were, which were both removed despite the popularity of parameterized 
modules at the time. (I believe Richard was behind the latter, by the way.)

The proposal does not suggest fundamentally changing Erlang either. 
Richard suggests that there could be further steps depending on how this 
one goes, but that's about it. Considering the feedback so far I 
consider it unlikely that this annotation would become mandatory unless 
there's a strong benefit to be had at the compiler or VM level, which 
does not seem to be the case. I would say it's also unlikely at this 
point that it would be required by default, and that would likely be the 
case for a very long time as long as most of the code in the wild does 
not use the annotation.

On the other hand the proposal solves some real issues (small in numbers 
but seemingly large in time wasted) and a number of users would like a 
solution. I believe it would be a more appropriate use of everyone's 
time to try and solve the problem, instead of just fighting against this 
one solution for reasons unrelated to its merits.

I suggested both editor improvements (and yes this means having to use a 
LS or beefier IDEs, fine by me) or an additional lint step (something 
similar to +bin_opt_info), both of which have their merit and their 
flaws. I am sure there are other much better solutions waiting to be 
found. There are also other related issues that can be explored and 
fixed, such as https://github.com/erlang/otp/pull/2995

By the way, if annotations are going to be a thing, it might be a good 
idea to make them more general so we can annotate other things, such as 
"pure function" / "side effect function" or "local send" / "remote 
send". I would personally love to easily identify message sends to 
remote nodes.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu