New EEP draft: Pinning operator ^ in patterns

[Svilen Ivanov]

When I tried this on one of our projects with about 34000 lines of
Erlang code in 140 modules, there was 180 +warn_unpinned_vars warnings.
Vast majority - 160 of them in tests where matching was used as an
assertion, and 20 in production code where matching of already bind
variables was also used correctly.
I suspect that the results will be similar for the rest of our
projects.
So for me proposed annotation will not be an improvement, I certainly
can live with it but prefer not to.

Best regards
/ Svilen

On Fri, 2021-01-22 at 11:00 +0000, Karl Nilsson wrote:
> So I took the pinning branch for a spin and ran it against the Ra
> library (https://github.com/rabbitmq/ra/pull/209) I have worked a lot
> on the last few years. I found 2 bugs and at least a couple of places
> where I am not really sure about the intent of the match and where it
> could be done better. At some point I will run it against the
> RabbitMQ code. Who knows what I will find there! 
> So thank you Richard, I take my hat (pun intended) off to you for
> this feature and for standing up for it against the onslaught of
> negativity around it. For me this feature, ad-hoc or not, addresses a
> real problem and will result in fewer bugs which makes me prepared to
> deal with any syntactic overhead it may carry.
> 
> I'd like to also address the often mentioned idea that functions
> should be "small" (whatever constitutes small) as if that is some
> kind panacea for writing good code. It is not. Quite the opposite.
> Arbitrarily small, local, single-use functions can make code almost
> impossible to read and reason about. This is especially the case in a
> dynamic language where you can't even rely on editor type hints to
> work out what the function accepts as input and returns as output and
> then possibly derive roughly what the function does. Instead you have
> an indirection where you have to skip to some other location in the
> file whilst trying to maintain the context of where the function was
> called. This indirection makes reading/context building very hard and
> IMO the most important feature of successful code (code that remains
> in use) is that it can be read and understood with minimal bother.
> 
> Just my 2 öre though...
> 
> On Fri, 22 Jan 2021 at 10:32, Nicolas Martyanoff <khaelin@REDACTED>
> wrote:
> > On 2021-01-22 11:02, Raimo Niskanen wrote:
> > > I am trying again, in hopefully a more civilized manner...
> > > 
> > > By constantly repeating that your opinion would not matter and
> > that someone
> > > has a plan to force this feature through you indirectly say:
> > > *) That the decision process for an EEP and the Technical Board
> > at Erlang/OTP
> > >     at Ericsson can not be trusted to make a good decision for
> > > the
> > Erlang
> > >     language and the community.
> > > *) That the community does not want this feature.
> > > 
> > > This is attacking the decision process itself instead of
> > contributing to
> > > the decision.  To me this feels like a way to force your point of
> > view
> > > through in this decision.
> > 
> > Try to put yourself in the shoes of those who reject the proposal:
> > 
> > - From the beginning, we are being told repeatedly that our answers
> > do not
> >   address the right part of the proposal, or are not valid
> > arguments, or are
> >   not the right way to argue. The last evolution of the debate is a
> > comparison
> >   to Trump...
> > 
> > - As I already asked, for all these messages we still have not
> > received any
> >   information about who has real authority on this type of change
> > to the
> >   language. You are talking about a "decision process", but for the
> > time being
> >   I see Richard and you trying really hard to make everyone believe
> > there is
> >   some kind of fair debate.
> > 
> > - The original proposal comes from someone who is not part of the
> > Erlang team.
> >   You, as part of the Erlang team, immediately sided with him and
> > started
> >   engaging with everyone in favor of the proposition. There has
> > been talks
> >   about going forward with making the operator mandatory, changing
> > scoping
> >   rules, still more changes... So yes, there is an agenda.
> > 
> > - As for "the community not wanting this feature", there are indeed
> > lots of
> >   developers here who believe that this kind of change is a mistake
> > (I'm
> >   obviously not talking about an optional warning, since it would
> > not modify
> >   the language), I'm saying it directly because it is true.
> > 
> > At the end of the day, this is about a proposition which, if
> > adopted, could
> > change a core aspect of the language in a non-backward compatible
> > way and
> > which would force all developers all around the world to eventually
> > change all
> > their code. And this is being discussed with you as single member
> > of the
> > Technical Board.
> > 
> > If you are the only one in charge of taking the final decision,
> > then it is
> > clear there is no real debate since you are obviously very much in
> > favour. If
> > you are not, then there is no real point in arguing for weeks
> > without an
> > official answer from the Erlang team.
> > 
> > -- 
> > Nicolas Martyanoff
> > http://snowsyn.net
> > khaelin@REDACTED
> 
>