Re: New EEP draft: Pinning operator ^ in patterns
Raimo Niskanen <[email protected]>
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <[email protected]> |
Thank you! Well put! / Raimo On Tue, Jan 19, 2021 at 12:56:01PM +0000, Karl Velicka wrote: > Dear list, > > I'm not bringing much in way of hard technical arguments, but I'd like to > share some thoughts about the proposal and community's reaction to it - I > hope that they will help steer the discussion in a more productive > direction, similar to what Raimo is trying to do here. I must say that it's > somewhat upsetting that posts like his or mine are even needed, one would > expect a lot more tact and and level-headed discussion to be shown in this > list... > > (FWIW, I had a fiery initial reaction to this myself, but luckily I chose > not to type anything at the time, as my opposition to the proposal has been > dwindling the more I think/read about it) > > There's been people describing the operator as "fly-droppings" and similar. > Firstly, this comes across as an intentionally derogatory name, which makes > me think that responders using such language are not looking to discuss in > good faith from the get-go. Secondly, what exactly makes ^Pattern "fly > droppings" but `foo(<<H:8, _:H>> = X) -> X.` is presumably perfectly > readable? I think this is largely (if not entirely) down to familiarity. > Let's not conflate those two things, and let's not pretend like adding > another glyph to our arsenal is somehow going to make everyone's brain > explode. I like language cleanliness as much as the next person, but there > is no need whatsoever to reach for strawmans about 5-char-wide walruses > that are obviously coming to eat us all. > > Next up, a lot of people are arguing about the syntax more than the feature > - to those I'd say "do you think the feature is useful/valuable aside from > syntactic implications?" If so, syntax can perhaps be revised. If not, I'd > encourage arguing about the semantics of the feature and leave syntactic > quibbles aside. FWIW, there have been some good discussion there, say re: > scoping rules. > > In addition, I feel like there's been a certain lack of forthcomingness > from Richard and/or the WhatsApp team (certainly in the initial post at > least) about the intent and larger picture of this change - there has been > a mention in this thread about the possibility of eventually making the > operator mandatory etc but none of that is in the proposal and I really > think it should be. I think it may be easier to sell the community on the > direction Whatsapp believes Erlang should be heading in rather than being > drop-fed certain aspects/features of it in isolation. > > Lastly, I wonder if there's some "ulterior" motive here. In quotes because > I don't think the motive is at all dishonest but I suspect there is one - > reading between the lines, there's been a few mentions about how the > current Erlang is more difficult to parse/analyse because match patterns > need extra information about which variables are already bound and to what. > Am I inferring correctly that this EEP also serves a simplification of the > language (from the POV of a machine), which is possibly related to some > internal static analysis that WhatsApp is doing/would like to do, or > perhaps is related to the fabled static typed Erlang that they are said to > be working on? This may well be something that the community at large be > interested in! > > That's all from me. I hope we can all take a deep breath (or a few, for > good measure) before sending our next messages to this thread and remember > that we are all a part of the same, and _already_ small Erlang community, > so I'd really like to see more posts in the vein of "let's see how we can > settle our differences" than "not on _my_ lawn!". > > All the best, > Karl -- / Raimo Niskanen, Erlang/OTP, Ericsson AB