New EEP draft: Pinning operator ^ in patterns

[zxq9]

Bingo.

On 2021/01/28 15:19, Nicolas Martyanoff wrote:
> On 2021-01-27 12:41, Richard Carlsson wrote:
>> 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.
>> [...]
>> 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.
>> [...]
>> 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
> 
> It now makes much more sense. I really wish people at WhatsApp working on this
> project were actually here on this thread; it would also have been a lot
> better if this had been clearly explained at the beginning. Because yes, it is
> now clear that there *is* an agenda to try to change fundamental things in
> Erlang (yes, I get, "incremental improvements", words are everything).
> 
> I really wish people who want to see a language go a different way just create
> a new language of their own instead of messing with what exists and is liked
> as it is. José Valim did it successfully with Elixir, so yes it is possible.
> 
> Of course, I get it, getting "adoption" (i.e. getting other developers to
> produce tools and libraries for free) is valuable, so why take a risk with a
> new language when you can try to pressure the existing community into
> accepting your changes ?

One note on creating other languages, which is also exactly the 
direction I would go with this. It could be Prology like Erlang but have 
some extras added in (after all, languages don't evolve or incrementally 
improve, they change into incompatible new languages over time that rob 
the old one of its name), be Elixir/Rubyish, be Pythonic-Erlang, 
whatever. Sky's the limit.

The key to making it easy to adopt in the short term would be to make it 
a *peer* language instead of a language that requires its own 
environment that must subsume the other one entirely and make Erlang 
hard to call, the new one hard to call from Erlang, or both hard to call 
from each other.

I'd love it if I could make tools like ZX be able to look at src/ with 
no magic prompting and just build out a full system with a mishmash of 
beam language source files, each module being written in whatever suits 
it best in terms of expression.

LFE is a lot closer to this ideal than Elixir, and actually I have plans 
to make LFE usable as a peer language right alongside Erlang from ZX.

This point is somewhat orthogonal to the original discussion, but I 
wanted to throw the idea out there as one of the things that an author 
of tooling would think about when considering which languages to put the 
effort into supporting. Elixir is a bridge too far for me right now 
because of the extra complications involved in its environment (it's a 
*huge* dependency to add in).

-Craig