New EEP draft: Pinning operator ^ in patterns

Richard Carlsson carlsson.richard@REDACTED
Tue Jan 19 12:56:06 CET 2021

There is nothing in this suggestion that affects the reuse of the same
variable within a pattern.
If it's a new variable that's supposed to have the same value in both
positions, it would look like before: "{X, X} -> ...".
If it's an already bound variable that occurs twice in the same pattern,
you'd mark both instances: "{^X, ^X} -> ...".


Den mån 18 jan. 2021 kl 08:25 skrev Torben Hoffmann <torben.lehoff@REDACTED

> Hi,
> I have written a lot of code where the function clauses used having the
> same variable twice a lot. Like, really a lot.
> f(X, X) -> ...
> This would be a real bummer to lose.
> It makes a lot of code really concise because you push the first decision
> to the front of your function clauses.
> Elixir allows the same, so nothing lost on that front.
> That said, I am rarely using an already bound variable in a match.
> The only place it may come up is in a case-statement, but still, very rare.
> I - like other comments in this thread - favour small function bodies,
> where the need for re-assignment to a variable is a lot smaller and the
> need for matching on an already bound variable is equally small, if not
> done in the function head.
> Erlang has, IMO, the advantage that if you've bound a variable you cannot
> change it. That is simple to grasp.
> In Elixir you can write
> def funky(x, x) do
>   x = x + 42
>   x
> end
> That takes a bit more explaining, which is the downside of abandoning of
> single assignment.
> I can live with this in Elixir because I use the same coding style (small
> function bodies), so the need for this is small in my code.
> There are times where I miss Pascal's assignment: x := 42 means that you
> are giving x a new value and x = 42 means comparison.
> I haven't coded Pascal in anger for ~30 years so it may be that my memory
> is kinder to this construct than it ought to be.
> At the end of the day I am happy with the way single assignment is
> implemented in Erlang, so I would be slightly annoyed by the proposed
> change, but I would be downright angry if reusing the same variable in the
> head of a function clause was changed.
> Cheers,
> Torben
> On Sun, 17 Jan 2021 at 13:45, Richard O'Keefe <raoknz@REDACTED> wrote:
>> Am I the only one who finds the word "pinning"
>> confusing?  I know what "pinning a bone" means.
>> I know what "pinning an insect to a board"
>> means.  I know what "pinning an enemy/opponent"
>> means in war, wrestling, or chess. I am not an
>> Elixir programmer (the syntax has always struck
>> me as, um, more pain than whatever other gain I
>> might get from Elixir), so I don't know what
>> "to pin" means in Elixir.
>> I am also confused by it being called an operator.
>> It appears to be an ANNOTATION, not an operator,
>> some sort of "hey I really meant to have an
>> already bound variable here" annotation.  It
>> certainly doesn't *act* like an operator.
>> If it were an operator, I'd be asking what ^X+1
>> meant and what ^1+X meant.
>> Since Erlang has two notions of equality, I
>> would be much happier with an optional style
>> rule that says "all variables in a pattern
>> must be new" (like patterns in Haskell, SML,
>> and so on) forcing you to show in the guard
>> which version of equality you wanted.  This
>> would be a pure restriction on existing
>> Erlang syntax; any code accepted under this
>> rule would also be acceptable under unrestricted
>> Erlang and would have the same meaning.
>> I note that none of the other functional
>> languages I use (Haskell, SML, OCaml, F#)
>> have any analogue of ^X and they don't need
>> it.
>> On Sun, 17 Jan 2021 at 21:18, Valentin Micic <v@REDACTED> wrote:
>>> > On 15 Jan 2021, at 17:35, Raimo Niskanen <
>>> raimo+erlang-questions@REDACTED> wrote:
>>> >
>>> > 1) Would the language be a better language with a mandatory pinning
>>> operator?
>>> >
>>> >
>>> I think this must always be our starting point.
>>> Without asking this question, we might wake up one day programming in
>>> C++ (not that anything is wrong with that… well, other than esoteric
>>> syntax).
>>> V/
> --
> @LeHoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list