New EEP draft: Pinning operator ^ in patterns

Richard Carlsson carlsson.richard@REDACTED
Tue Jan 19 14:30:06 CET 2021


Hi Torben! I don't have any separate analysis tools, basically just some
printfs in the compiler. The easiest way to test this on your own code is
to build the branch from the demo pull request:
https://github.com/erlang/otp/pull/2951 - then compile your code
with +warn_unpinned_vars.

        /Richard


Den tis 19 jan. 2021 kl 14:13 skrev Torben Hoffmann <torben.lehoff@REDACTED
>:

> 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 <carlsson.richard@REDACTED>
> 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 <
>> 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/
>>>>>
>>>>
>>>
>>> --
>>> http://www.linkedin.com/in/torbenhoffmann
>>> @LeHoff
>>>
>>
>
> --
> http://www.linkedin.com/in/torbenhoffmann
> @LeHoff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210119/b18a7c66/attachment-0001.htm>


More information about the erlang-questions mailing list