Re: New EEP draft: Pinning operator ^ in patterns

Hi Richard,

Thanks for clarifying.
In that case my biggest worry is off the table - I have a lot of code that
would be broken by my misinterpretation, so I'm glad I misread the
discussion in this thread.

Given that the migration path doesn't break things nor take away from
binding twice in a pattern match (my biggest beef), it boils down to
whether this is a good thing to have or not.

I'm of the opinion that matching against an already bound variable should
almost exclusively be done in a function clause header or in a case clause
(as your example).
Your analysis of the OTP code base shows that this isn't used much, ie,
fixing that would be a small thing.
If you could release the code to spot these usages others could run it on
their own code base and be relieved that they don't have a huge body of
things to update.

As pinning would make the intention of the code clearer I am in favour of
introducing it.
Intention is one of the most important aspects of code maintainability and
this EEP provides that at a small cost.

Cheers,
Torben


On Tue, 19 Jan 2021 at 12:56, Richard Carlsson <[email protected]>
wrote:

> 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} -> ...".
>
>         /Richard
>
>
> Den mån 18 jan. 2021 kl 08:25 skrev Torben Hoffmann <
> [email protected]>:
>
>> 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 <[email protected]> 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 <[email protected]> wrote:
>>>
>>>>
>>>> > On 15 Jan 2021, at 17:35, Raimo Niskanen <
>>>> [email protected]> 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
>>
>

-- 
http://www.linkedin.com/in/torbenhoffmann
@LeHoff