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
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
