New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

Den tors 21 jan. 2021 kl 23:55 skrev Loïc Hoguin <essen@REDACTED>:

> I agree that ^ can make some code more
> obvious, but I definitely don't want this to be enforced everywhere.
> Socket messages, monitors and other message refs, tests and other
> similar places would not gain in readability in my opinion. The places
> where readability increases are those where matching is not expected,
> like most of your examples seem to be. Though in some of those cases a
> comment would be much better.
>

I do agree that this is the main weakness of the suggestion. In many normal
cases, the ^-annotation can look superfluous. But it does provide
uniformity, over the whole codebase. You know you can trust it, everywhere,
and even in a short function it can quickly guide your eyes to see that
there's some important matching going on. So I think it can be worth it.
But if there's anywhere I have doubts, it's this point - if it's worth
having it everywhere, compared to just falling back to guards instead.

You say ^ indicates that the match is intentional, and in a perfect
> world perhaps that's true, but in the real world you'll also end up with
> misplaced ^ that should not be matches at all, as some of your examples
> show.


Well, those examples had misplaced matches precisely because there was no
warning and no requirement for the programmer to state exactly what they
meant. If there had been a warning and a requirement to do something
(annotation or guard) to silence that warning, the mistake wouldn't have
made it there in the first place. That's no differenft from when e.g. the
warning for unused variables became default - among the harmless unused
variables, it also revealed some existing mistakes in the code;  and
nowadays you don't get new mistakes like that because the compiler keeps
reminding you. For already-used variables: if you indended it and ^X
doesn't exist, you get an error, and if you didn't intend for X to be bound
before but it was, you get a warning.

As a result, the ^ alone does not convey much information. You don't
> know why the dets:check_file_header/2 function is called twice, a

comment would work out much better. (A comment explaining why one call
> is protected in a try..catch and one isn't would be great as well.)
> Maybe parse_term/3 really does have to return the same "D" value, but ^
> only tells you it's expecting the same value, it doesn't tell you why.
> And so on.
>

Yes, but what I'm saying is that if the author, who presumably did
understand why they did something, had been told about these matches by the
compiler at the time they wrote the code, they would have been likely to
either change the code because it wasn't what they meant, or they would
have marked the match as intentional (even if they don't add any further
comments), and then we could probably trust that the code works the way it
was intended at the time. But as the code stands now, we can only either
guess, or try to find them and ask if they can tell whether this is
intentional.

    /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20210122/237e6005/attachment.htm>