New EEP draft: Pinning operator ^ in patterns

[Austin Ziegler]

I’m mostly an interested bystander (our company uses Elixir, but I
have been interested in Erlang and the BEAM for quite a few years
before that happened). I can READ Erlang code just fine (well,
mostly—I had to look up what =:= meant), but I don’t yet feel
comfortable writing new Erlang code.

> >Can you please explain why you think the proposal is half-baked.
> The proposal is half baked because it introduces a notation which is in no way compatible or similar to existing Erlang syntax. The proposal is half baked because it will work completely only when the backward incompatible change is introduced in the future as discussed earlier. From this perspective this proposal is presented as something self contained and small, but in reality it is thought of as beginning of longer process leading to change in fundamental part of the language.

I’ll grant that it’s not compatible with existing Erlang syntax—one
won’t be able to compile a program written with this on versions lower
than Erlang than this is introduced with. This is no different than
any other syntax introduced in _any_ language. Has Erlang syntax not
changed at all since it was first made available to the world? At all?
I seem to remember that maps were introduced some versions ago, and of
course that wouldn’t be compatible with older versions of the
compiler.

I will completely disagree with your reading of the proposal that “it
will work completely only when…”. No, as I’ve read the original
proposal and the clarifications made since, it will work completely as
intended out of the box if implemented. This _allows_ for the explicit
marking of matches to increase the readability of code…which will
ultimately make Erlang itself more accessible to people interested in
the BEAM.

I’ve seen straw-men raised that functions should be small. As a rule,
that’s too strict. Functions should be as small as it makes sense to
express their concept. In most of the ~30 languages I’ve written
software in over my career, I usually start with larger functions and
then refactor them out as it makes sense to do so and the
expressiveness of the containing function is improved by the
refactoring. As Richard has said, the pinning annotation would
absolutely be of _great_ benefit during this refactoring process.

As an Erlang “newbie”, I really think that this would benefit the
people here who have spoken out least: those who _do_ find it harder
to have to perform the same “have I seen this variable before”
accounting in their head as the compiler does.

> > The feature is not strictly necessary, but I and many others recognize that it would improve readability.  Must all changes that are not strictly necessary be forbidden?  How can we then achieve improvement?
> When we speak about changes in core language, leading to backward compatibility I believe yes only necessary changes should be done in this way. Improvement is achieved in other ways serving more developers in less intrusive way. Actually nearly all changes in Erlang - when I look at release notes - solve real problems in the way which does not have potential of impacting developers not interested in a specific change. The huge discussion about the pinning operator is because this change is not like the others.

So, if one had no interest in the implementation of maps, one can
simply ignore the fact that the syntax and feature exist in modern
Erlang…and any libraries that one might use? All syntax changes have a
negative impact on someone’s view of readability. The pinning
annotation is exactly like other Erlang syntax changes that have
happened. Richard has worked with a large Erlang codebase with a large
team, and that team noticed something that cost real developer time
and velocity. Thus, this suggestion that could make adoption of Erlang
at team scales an easier sale to management.

Let’s say that you’re right and that this is only useful if and when
pinning is made mandatory. There are several points to this:

1. According to most of the reports made so far by people giving this
a _try_, this would affect 1% of their codebase. Or less.
2. I don’t see this EEP being accepted soon enough for Erlang/OTP 24
(I could be wrong), so I’d guess this could show up in the Erlang/OTP
25 development cycle (so, a 2022 release).
3. It’s definitely not going to be mandatory immediately, and it’s
controversial enough that the warning might be turned on by default
(but still able to be turned off) for maybe Erlang/OTP 27 (2024,
right?).
4. And maybe the option to turn off the warning is removed in
Erlang/OTP 28 or 29 (2025, 2026).

Aside from the fact that I don’t agree with you about this being
useful only if mandatory, what exactly is wrong with a likely ~4–5
year schedule for this sort of change? I’ve seen _plenty_ of breaking
changes listed in the last 5 years of release notes on the Erlang
website (at least one syntax / warning change, and many more changes
to things like erlang_interface and parts of the stdlib which have had
functions dropped after 1–2 versions).

> > Can you please explain why you state that the feature proposal is core-breaking?  I have tried to explain many times why I do not agree to that, and still this statement comes up instead of counter-arguments.
> It changes the way pattern matching works, so when it is made mandatory it is breaking by definition.

Not initially. And it may never be made mandatory if it turns out that
there’s no adoption of the feature (frankly, I think that people will
adopt the feature because it will likely make onboarding new
developers who may also be new to Erlang faster).

> The thing making this whole discussion a little bit unreal is that we are talking about a change in the core language solving a problem which was not really raised that much. I believe the closer something is to the core of the language the more important reasons to make a change should be. No one has any problem when a new stdlib function or module is added. No one has any problem if some great new functionality - like maps - is added with backward compatibility and value for potentially all developers. But when a proposal is made to introduce some alien notation to solve esoteric problem, and two people arguing for it argue as it were another maps or some other very valuable change, sending tens of long emails - it feels otherworldly a little.

What is esoteric to you, with many years experience reading and
writing Erlang, may be an unasked question or point of confusion to
people who are exploring Erlang (considering adoption) or reading
Erlang (like me). The question I have for all the people who think
that this is an “esoteric” problem…do you not remember what it was
like when you first started _learning_ Erlang? Erlang may _feel_ like
Prolog, but it isn’t Prolog anymore, and hasn’t been for a very long
time.

I think that Raimo and Richard have done an admirable job of
explaining what is a fairly good idea to improve readability in the
face of people who have forgotten what it‘s like to deal with Erlang’s
fairly alien syntax as compared to most programming languages that
people learn first.

-a
-- 
Austin Ziegler • halostatue@REDACTED • austin@REDACTED
http://www.halostatue.ca/ • http://twitter.com/halostatue