Re: New EEP draft: Pinning operator ^ in patterns

Attila Rajmund Nohl <[email protected]>
Newsgroups gmane.comp.lang.erlang.general,gmane.comp.lang.erlang.eeps
Message-ID <CAFkcMa_nWc_80qKM=+rfFywfsv9p-tV8SksoVD4XStFp0ihqwQ@mail.gmail.com>
Richard Carlsson <[email protected]> ezt írta (időpont: 2020.
dec. 24., Cs, 21:10):
>
> The ^ operator allows you to annotate already-bound pattern variables as ^X, like in Elixir. This is less error prone when code is being refactored and moved around so that variables previously new in a pattern may become bound, or vice versa, and makes it easier for the reader to see the intent of the code.
>
> See also https://github.com/erlang/otp/pull/2951
>
> But
> suppose that someone adds a binding of the name `T` further up in the
> function body, without noticing that the name is already in use:
>
>   g(Stuff) ->
>       ...
>      T = q(Stuff) + 1,
>       io:format("~p", [p(T)]),
>       ...
>       Thing = case ... of
>                   {a, T} -> T;
>                   _ -> 0
>               end,
>       ...
>       {ok, [Thing|Stuff]}.
>
> Now the first clause of the case switch will only match if the second
> element of the tuple has the exact same value as the previously
> defined `T`.

I admit I had a similar bug a couple of months ago. Took some time to
find it, so I see the rationale to introduce an option to tell the
compiler "I expect the variable to be pinned here". But I don't think
this is the right approach to avoid these kinds of bugs. The ^
operator must be optional at introduction (to avoid breaking lots of
legacy code), but if it's optional, it's usage will be also optional -
and more importantly inconsistent. Some codebases will use, some not
and in the worst case it's usage could be on a function-by-function
clause, meaning that if I don't see the ^ operator in code like above,
I can't be sure it was intentionally or accidentally left out. I'm not
sure that a code like

case ... of
  {a, ^T} -> T;

will be more clear than

case ... of
  {a, TempT} when T == TempT -> TempT;

For this later case we don't need a new operator and the code would be
more consistent with the idioms used in funs to avoid shadowing.

> Ho ho ho,
>
>         /Richard & the good folks at WhatsApp
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.