New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

Den tors 21 jan. 2021 kl 18:21 skrev Nicolas Martyanoff <khaelin@REDACTED>:

> While I agree that some of the examples you give are indeed confusing, why
> would a warning flag not be good enough ? It would have multiple
> advantages:
>
> - Anyone would be able to either warn or totally reject (with
>   warnings_as_errors) these kinds of construction.
> - Anyone who does not care would be able to totally ignore it (and please
> do
>   not tell me that this new operator/annotation would be optional, there
> is no
>   way it would not be become mandatory at some point).
> - This would have no effect on existing codebases, therefore removing any
>   migration cost. I cannot even begin to explain how bad of an idea it
> would
>   be to force every Erlang developer all other the world to patch all their
>   projects because something that worked perfectly before now requires a
>   cryptic annotation.
>

As you yourself note, the warning is likely to eventually be made the
default (if generally accepted), and this means for most code bases these
days that they'll be patching their code anyway, just in order to compile
cleanly with default flags - something most projects want. In practice
then, it makes no difference if the patching consists of adding a ^, or
inventing a new temp variable and adding a guard test, except that the
latter is much harder to automate.

- This would not affect the language itself in any way, sidestepping any
>   discussion about the syntax itself.
>

As discussed in other replies, we could do it this way - if the ^-notation
doesn't merit including in its own right as a way to write clear and
concise patterns. But I'm arguing that these examples are better with ^
than with guards.


> Now you could argue that you wish to be able to use these kinds of
> constructions on occasion, but then surely you would agree that checking
> equality in a guard is far more explicit and therefore more readable.
>

This is where I don't agree - especially after looking at the experimental
diff and thinking "how readable would all this be with plain guards
instead?".

When you read something like

    receive
        {ssh_cm, SSH1, {open, Chn1, RemoteChn, {session}}} when SSH1 =:=
SSH, Chn1 =:= Chn ->

you both need to look at the pattern and note which variables are in which
positions, as well as read and understand all the guard expressions, before
you can say "ah, it only matches when this position is the already existing
SSH and that position is the existing Chn binding. This is tolerable, but
not great.

When you read the same code written with ^-notation, you can see what it's
doing at only a glance:

    receive
        {ssh_cm, ^SSH, {open, ^Chn, RemoteChn, {session}}} ->

and you don't need to think about whether those extra variables have
further uses, or if the guards were correctly written.

    /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210121/c6bfd52b/attachment.htm>