New EEP draft: Pinning operator ^ in patterns

Richard Carlsson carlsson.richard@REDACTED
Fri Jan 15 13:34:18 CET 2021


There have been many strong reactions in this thread, so let me give you
some statistics to show how much this feature of using bound variables is
actually used in practice. I checked the entire OTP codebase: there are
just over 1300 modules, and in total about 595000 variable occurrences in
patterns, of which only 3350 are already bound.. That makes 0.56% of all
variables in patterns - about once in 200 to make it simple. On average,
that's 2-3 usages per module - some modules using it more and some not
using it at all.

I find it hard to see, then, why it should be a big issue to ask
programmers to annotate these few occurrences for readability and
maintainability. It's certainly not as big of a change as for example when
the warning for unused variables, unless prefixed with _, was made the
default.

Imagine a world where Erlang had not allowed already-bound variables in
patterns (forcing you to use the idiom "X1 when X1 =:= X -> ...", as in
e.g. Haskell), and that someone now came with the suggestion that to make
things simpler, we could just implicitly match on the value of X if X is
already bound. The old me from my university days would probably have said
"that's really elegant, let's do it". But the
maintainability-and-readability me, with experience of very large code
bases, large numbers of developers, and many relative newcomers to the
language, would say "aw hell no". This is a cute feature, but it carries a
large cognitive cost and is not worth having compared to how relatively
little it is used. Being explicit about intention is much more important.

        /Richard


Den tors 24 dec. 2020 kl 21:10 skrev Richard Carlsson <
carlsson.richard@REDACTED>:

> The ^ operator allows you to annotate already-bound pattern variables as
> ^X, like in Elixir. This is less error prone when code is being refactored
> and moved around so that variables previously new in a pattern may become
> bound, or vice versa, and makes it easier for the reader to see the intent
> of the code.
>
> See also https://github.com/erlang/otp/pull/2951
>
> Ho ho ho,
>
>         /Richard & the good folks at WhatsApp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210115/85ec9e14/attachment.htm>


More information about the erlang-questions mailing list