New EEP draft: Pinning operator ^ in patterns

[Loïc Hoguin]

On 15/01/2021 13:34, Richard Carlsson 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.

I am more or less in the "no opinion" camp. I get the argument and why 
it would be useful in some cases, but I do not see much point in using 
it myself.

1 occurrence every 200 variables in patterns is even less than I thought 
it would be. My own code probably does this more often. But it's still a 
rare occurrence and it solves potential issues that very rarely happen 
(for me, again).

I do question how many projects will use this. I suspect the strong 
reaction is an indication.

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

It may or may not be more readable to newcomers, but I'd like to see the 
data on that. I don't think it helps newcomers too much because the pain 
point is not being able to re-assign variables, not identifying what is 
a match from what is an assignment. The absence of this operator might 
make this more obvious since you'll get to see what happens when you try 
to re-assign a variable.

Being explicit about intention is important, but there are other ways to 
be explicit. As far as I'm concerned, documentation provides intention, 
and tests prove it. Readability is ensured by keeping function clauses 
small. This operator would add little more on top of that.

I would be OK with an experiment, but I don't know what metric would be 
used to view it as successful.

I'm also wondering what the drawbacks will be. Perhaps there will be 
none, perhaps people will fail to adapt to this, or something else 
entirely. The unused variables warning only works for me because I don't 
warn errors for test compiles, it becomes a pain otherwise.

Cheers,

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