Re: New EEP draft: Pinning operator ^ in patterns
Frans Schneider <[email protected]>
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <[email protected]> |
+1 So many good reasons were given not to introduce the pinning operator before in this list. Very worrying! Regards, Frans On 1/14/21 3:50 PM, A. G. Madi wrote: > I completely agree with Nicolas. This makes me very nervous. > > On Thu, Jan 14, 2021 at 08:41 Nicolas Martyanoff <[email protected] > <mailto:[email protected]>> wrote: > > On 2021-01-14 14:13, Richard Carlsson wrote: > > The way I planned it is: > > 1. Even from the start, pinning will always be allowed, > without requiring > > any flag to opt in. This does not tell you about existing uses of > > already-bound variables, but you can start using pinning right > away for > > readability and for avoiding bugs when refactoring. The compiler > will > > always tell you if a pinned variable doesn't exist, so you don't > > accidentally accept any value in that position. > > 2. You can enable warnings at your own pace in order to start > cleaning up > > your code. > > 3. In a following major release, the warnings will be on by > default, but > > you can disable them to compile old code. > > 4. In a distant future, it might become an error to not use ^ > to mark > > already-bound variables. > > After reading this thread, I must say this proposal makes me > uneasy. One of > the things I always liked with Erlang is the simplicity and > clarity of its > syntax. Matching variables by name is perfectly readable to me, > and I never > had any problem of the sort refactoring code. Adding a new > operator adds > noise and transforms something simple (using the same name to > refer to the > same value) into something cryptic. > > The fact that you envision a future where not using the operator > would signal > an error is even more worrisome. I have nothing against improving > the core > parts of the language (maps were a life changer for example), but > this kind of > change feels really foreign to the simplicity of the Erlang syntax. > > And at the risk of sounding too harsh, I would add that while I do > not mind the > existence of Elixir (quite the opposite, it brought a lot of fresh > air to the > entire BEAM ecosystem), I would really like Erlang to remain > Erlang; in that > spirit, I see a new operator to "annotate" a perfectly clear and > working > syntax as useless. > > Regards, > > -- > Nicolas Martyanoff > http://snowsyn.net <http://snowsyn.net> > [email protected] <mailto:[email protected]> >