New EEP draft: Pinning operator ^ in patterns

2QdxY4RzWzUUiLuE@REDACTED 2QdxY4RzWzUUiLuE@REDACTED
Fri Jan 15 16:04:17 CET 2021


On 2021-01-15 at 13:34:18 +0100,
Richard Carlsson <carlsson.richard@REDACTED> wrote:

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

In a 40+ year career in software development, I never used Erlang in
anger (although I did work on a couple of very large, highly available,
distributed telecom systems/platforms, but I digress).

That said, I draw exactly the opposite conclusion from those results:
If only that much code in such a large corpus would benefit, then why
implement pinning?

Of the 3350 variable occurrences you want someone else to annotate and
maintain (multiple times, according to your incremental implementation
plan, not to mention updated tests, documentation, etc.), how many are
confusing?  How many already have human readable comments that explain
what's going on?  How many have had bugs opened against them?

In my very limited Erlang experience, I've found the existing compiler
warnings good enough, and "fell into" Craig's solution of using a more
descriptive name (like FilteredX, or XWithoutSpaces, or even _X when the
functions are really tiny) or breaking a local fun out into a "real"
function to supress the warning and make my code more readable and/or
more maintainable.  It's hard to say for sure, of course, but I don't
know whether a more complicated language would have been better (or
worse, or how) than what I have experienced.

-- 
“Whoever undertakes to set himself up as a
judge of Truth and Knowledge is shipwrecked
by the laughter of the gods.” – Albert Einstein
Dan Sommers, http://www.tombstonezero.net/dan


More information about the erlang-questions mailing list