New EEP draft: Pinning operator ^ in patterns

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Thu Jan 21 14:41:41 CET 2021

On Wed, Jan 20, 2021 at 1:47 AM Chris Rempel <csrl@REDACTED> wrote:

> 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.
This one has a valid concern. When you start numbering your variables, you
also introduce an order on them in code. As you manipulate code in an
editor, these numbers tend to require frequent updates. Even if you want
the numbers, having the pinning ability as an interim would help. The
ability to (recursively) rebind a new value to a name is the common way
functional languages handle this, whereas the unification check is closer
to the Prolog heritage. There are good reasons for both, but one should
definitely have a way to turn the Prolog variant into the FP variant. FWIW,
I've always found the rebinding to be the preferred default, since that's
what I'm most often interested in doing. The Erlang variant often just
breaks my code, and I'd much rather write an explicit assertion in the
program if I need it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list