New EEP draft: Pinning operator ^ in patterns

[Torben Hoffmann]

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/
>>
>

-- 
http://www.linkedin.com/in/torbenhoffmann
@LeHoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210118/ae23adaf/attachment.htm>