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

[Loïc Hoguin]

Thanks for bringing this to our attention.

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.

This

f(X, Y) ->
     case X of
         {a, ^Y} -> {ok, Y};
         _ -> error
     end.

does nothing to me. The ^ is rare enough that you will scratch your head 
to remember what it's about and what the rules are, especially in more 
involved scenarios such as

f(X, Y) ->
     F = fun ({a, ^Y, Y})  -> {ok, Y};
             (_) -> error
         end,
     F(X).

The description of this snippet is also not clear: "In this case, the 
pinned field refers to the value of the function function parameter, but 
there is also a new shadowing binding of Y to the third field of the 
tuple. The use in the fun clause body now refers to the shadowing 
instance." - what's the point of allowing this monstrosity? That's just 
being too smart for your own good.

If annotations are generalized we could instead have

f(X, Y) ->
     case X of
         {a, ^match Y} -> {ok, Y};
         _ -> error
     end.

and we could use them for other things such as

^remote Pid ! Msg

which can then be used by other tools to help better understand the 
code. I don't think we would end up with too many annotations ultimately 
so using a single word for this is probably enough. No opinion on the ^ 
character.

Since this is annotations, this ought to be optional, although of course 
teams may decide to force the use of ^match in their own projects along 
with the related compiler warnings.

Cheers,

On 21/04/2022 14:32, Leonard Boyce wrote:
> I'm copying the Erlang Questions ML with this post since there was
> significant and heated discussion regarding this EEP and not all ML
> subscribers have joined the forum.
> 
> On Wed, Apr 20, 2022 at 10:20 PM Bryan Paxton via Erlang Forums
> <noreply@REDACTED> wrote:
>>
>> starbelly EEF Board
>> April 21
>>
>> EEP-0055 (https://github.com/erlang/eep/blob/master/eeps/eep-0055.md) was submitted on
>> 21-Dec-2020.
>>
>> An accompanying implementation (https://github.com/erlang/otp/pull/2951) was submitted in which a lot of conversation ensued.
>>
>> It was decided that the EEP would not be set for inclusion in OTP-24, per the time table at that juncture and that it would be revisited prior to OTP-25. OTP-25 is now at a point where this is not possible.
>>
>> That said, I wanted to start a topic here about the EEP and gun for inclusion in OTP-26.
>>
>> I would point to @kennethL’s last comment (https://github.com/erlang/otp/pull/2951#issuecomment-770878570) on the PR as a starting point for discussion.
>>
>> I suppose my overarching question here is : Is this still on the table? And if so, what are the road blocks? Kenneth pointed out some possible roadblacks that needed investigation, but it’s not clear to me what happened after that.
>>
>> Of course, since I’m raising this topic, I’m obviously in favor of the operator I’d also be happy to work to drive it forward.
>>
>> ________________________________
>>
>> Visit Topic or reply to this email to respond.
>>
>> You are receiving this because you enabled mailing list mode.
>>
>> To unsubscribe from these emails, click here.
>>
>>

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