New EEP draft: Pinning operator ^ in patterns

Karl Velicka karolis.velicka@REDACTED
Tue Jan 19 13:56:01 CET 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210119/be7aeca1/attachment.htm>


More information about the erlang-questions mailing list