New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

Den tis 19 jan. 2021 kl 13:56 skrev Karl Velicka <karolis.velicka@REDACTED
>:

> 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!
>

Here's another one I should have answered earlier. Although it's no secret
and it's been written about in some places, I'm also sure that not everyone
heard it: During 2020, a team at WhatsApp - including myself as an external
consultant - was working on prototyping a "modernized Erlang", exploring
various ideas for making Erlang a better language for large scale
development. If there's a short way to summarize what that means, it might
be "giving you faster feedback". The longer it takes to understand
something, and the longer it takes for you to find out after you made a
change that something is wrong, the slower development gets. Especially
when you have many people working on the code and you have a large code
base that is constantly being modified, this is perhaps the most important
thing today for a language.

The main thing that the team focused on was trying to find a model of
static typing that could work in practice for real Erlang code (of which
WhatsApp has a lot) - one that could give you quick feedback (even in the
editor) and complete certainty that all checked parts of the code had no
type errors (thus not like dialyzer). As you may also have heard already,
this direction was put on ice at the end of 2020, because it seemed like it
couldn't provide a transition route quickly enough. The project continues,
but for now focusing on incremental improvements. But the team also looked
at things like scoping, naming, modules, and data types, and is very
actively contributing to the Erlang Language Server. The PR for column
numbers in error messages (see https://github.com/erlang/otp/pull/3006) was
also a result of this project.

As the project changed direction, we thought that we should at least try to
push out those ideas that seemed viable and useful as incremental changes
on Erlang as it is. The pinning part seemed to be the least complicated and
providing most benefit in the short term. Other things we tried with regard
to scoping and naming were not as "finished", and it's harder to say
exactly what the end goal should be, only that pinning would enable more
uniform and predictable scoping rules no matter which direction you take
next. That said, starting this year I'm only taking an advisory role for
the project, and I'm doing this out of my own invested interest in Erlang.

        /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210127/0d960496/attachment.htm>