<div dir="ltr"><div>Dear list,</div><div><br></div><div>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...<br></div><div><br></div><div>(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)<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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!<br></div><div><br></div><div>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!".</div><div><br></div><div>All the best,</div><div>Karl<br></div></div>