[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[Loïc Hoguin]

Because it allows the code to be more explicit in a way that tools can 
benefit from.

I do not personally think the ^match or the pin ^ is terribly useful, 
but I think annotations in general very well COULD be. Note that I 
assume that any additions of annotations to the language would be done 
as an experimental feature first, which the Erlang compiler now should 
be able to do better.

The Erlang language has had many experiments in the past, the most 
infamous of which is tuple calls and its companion parameterized 
modules. Them being added to the language as experimental does not mean 
the feature is going to stay forever. It has to show proof in practice 
that it is worthwhile.

About my ^remote example, we probably would have ^remote set when 
matching the Pid originally, not in the send call, though:

#state{pid = ^remote Pid} = State,
Pid ! Msg

One could imagine enabling additional checks on this annotation, such as 
validating that Pid is indeed a remote pid before sending messages to 
this process. Coupled with a check that any other sends are local-only 
and you end up with a project where it is easy to identify when messages 
are sent over the distribution, which is HUGE for some projects.

This is similar to what the pin ^ operator is doing, except in a 
different context. And that's why I would like to see a more general EEP 
for annotations. I have no strong opinions on the syntax it should use.

On 25/04/2022 16:58, Stanislav Ledenev wrote:
> One question - why? Just because we can?
> Erlang is doomed, Sorry Joe, we f**d things up.
> 
> пн, 25 апр. 2022 г. в 16:42, Loïc Hoguin <essen@REDACTED 
> <mailto:essen@REDACTED>>:
> 
>     I do not see what has changed in the EEP to warrant taking another look
>     at it. In particular, it still is a specialized use case of annotations
>     which I would be fine adding to the language as long as they're
>     generalized.
> 

-- 
Loïc Hoguin
https://ninenines.eu