New EEP draft: Pinning operator ^ in patterns

[Chris Rempel]

Hello,

> I agree about the beauty of Erlang's simplicity. For this particular
> suggestion I, personally, feel that because Erlang "hides" if a variable
> occurence is a binding or a matching in the knowledge if the variable has
> occured before or not, it may be too simple because it is slightly ambigous.
>
> Therefore I think that although annotating matches would make the language
> less simple it would improve clarity by making intention explicit.
>
> I can live without this, have so for the last 20 years, but I think Erlang
> would be a slightly better language with pinning than it is without it.
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB

I find a different conclusion in this, with how I think when coding in Erlang.
Knowing a variable always has the same value after first use, whether assigned
or pattern match, and the value never can change, is such simple concept to
work with.

From the EEP:

f (X, Y) ->
  case X of
    {a, Y} -> {ok ,Y};
    _ -> error
  end.

would no longer be valid (at some point in the distant future when pinning is
mandatory), and would have to be written:

f (X, Y) ->
  case X of
    {a, ^Y} -> {ok ,Y};
    _ -> error
  end.

yet today we can already write:

f (X, Y) ->
  case X of
    {a, Y2} when Y2 =:= Y -> {ok ,Y2};
    _ -> error
  end.

So, for those who want this EEP in order to be more explicit, why do you not
write your code in that third form and introduce an EEP requesting a compiler
flag that you can use to generate a warning in the first form above, so that
you rewrite it in the third form. The second form flies in the face of how I,
and apparently many others, think in Erlang. The pinning operator is
extraneous, and in fact determintal to that way of thinking.

The good thing about this EEP is that it addresses variable shadowing.  It has
always bugged me that variable shadowing was a thing in Erlang.

f(X, Y) ->
  F = fun
    ({a, Y}) -> {ok, Y};
    (_) -> error
  end,
  {F(X), Y}.

That generates the shadow variable warning currently, and `f({a, 1}, 2)`
returns `{{ok, 1}, 2}` which is just wrong as it breaks (in my view) the rule
that a variable value never changes.  And so pointlessly this must be
rewritten like so:

f(X, Y) ->
  F = fun
    ({a, Y2}) when Y2 =:= Y -> {ok, Y2};
    (_) -> error
  end,
  {F(X), Y}.

The pinning operator "fixes" this by allowing for:

f(X, Y) ->
  F = fun
    ({a, ^Y}) -> {ok, Y};
    (_) -> error
  end,
  {F(X), Y}.

But in both cases, I have to explicitly say, hey Erlang, don't break your own
rule that a variable value never changes. To me this EEP is fixing the problem
in the wrong way.

So, if there is any proposal to put forth, in my view, it is to get rid of
variable shadowing.

Also, already in this thread it is now being mentioned to have variable
rebinding support. If this EEP erodes such a core tenant (in my view) of
Erlang such that it leads to variable rebinding, it should be rejected on that
alone (in my view).

But the part of the EEP that just completely nullifies it is:

> In this case, there is no new binding of Y, and the use of Y in the fun
> clause body refers to the function parameter. But it is also possible to
> combine pinning and shadowing in the same pattern:
>
> f(X, Y) ->
>     F = fun ({a, ^Y, Y})  -> {ok, Y};
>             (_) -> error
>         end,
>     F(X).
>
> In this case, the pinned field refers to the value of the function function
> parameter, but there is also a new shadowing binding of Y to the third field
> of the tuple. The use in the fun clause body now refers to the shadowing
> instance.

You now have two variables named the same thing with different values. It
breaks fundamental way of thinking in Erlang.  There is zero value in allowing
this. Use a different variable name.

The EEP Rationale section is likewise problematic, but copying it here and
responding to each point is tiresome.

So, I'd like to propose that any EEP added to https://github.com/erlang/eep/
is done in a PR and left open for reviews/comments on the PR for a period of
time. There is much in the EEP that I would comment on, line by line.

There has been concern on the list that this discussion has not remained
technical and on point to the value of the EEP, and I would suggest the fault
lies in the tool being used to elicit feedback (e-mail). That concern would be
addressed by allowing people to comment line by line on the EEP and discuss
the specific points of the EEP in the PR itself. And we can avoid blame being
thrown around about people having or not having read the EEP.

Regards,

Chris