[erlang-questions] -protocol declartion idea, worth an EEP?

[Joe Harrison]

> One of the things I've wanted for a long time in Erlang is
> a way to check message passing. Now that we have the
> Dialyzer, it occurred to me that there's a simple thing we
> could do that wouldn't achieve everything we might want
> (it's not UBF) but might be useful in catching typos at least.

I'm actually working on exactly this at the moment. Though I'm
not relying on Dialyzer, there has been work on using Dialyzer
for this purpose:

"Detection of Asynchronous Message Passing Errors Using Static
Analysis" by M. Christakis and K. Sagonas

> Before writing it up as an EEP, I thought I'm check with the
> mailing list whether it makes sense to other people. It seems
> like the kind of thing that must have been thought of before,
> so maybe there is some flaw in it that I'm not seeing.

The problem I see is simple. If you have an irrefutable pattern,
it covers *all* of your receive specifications:

receive
  A -> ok
end.

> If you want to specify that a function doesn't receive
> anything, use 'receive none()'; any empty OptRcv says nothing
> about the function's protocol.

I disagree. This would mean that all "pure" functions require
annotations. This seems pretty tedious.

> This would not let us check that sends and receives matched up
> properly, although part 2 of the EEP would address that. But
> it would provide
> (1) a place to document the programmer's intentions
>     about the messages a process should receive

I love this style of programming. We should always let the
programmer communicate their intentions to the compiler.

> (2) a way to check that patterns in receives were supposed to
>     be there, catching typos

See my irrefutable pattern comment above.
I do however, think it would be very useful in a classroom
setting. We teach our undergraduate students Erlang and
one of my anecdotal observations is something similar to
the following:

client(Server) ->
  Server ! hello,
  receive
    akc -> ok
  end,
  client(Server).

server() ->
  receive
    {hello, Client} ->
      Client ! ack
  end,
  server().

In these settings I believe the analysis would be useful.
In OTP settings, I think that the headers of the
handle_call, handle_cast, and handle_info functions serve
as informal receive specifications.

> (3) a way to check that everything that is supposed to be
>     received might be received somewhere; this would have
>     false negatives, but it's still better than what we have.

I agree, it's better than nothing. I feel like the biggest
point of contention would be the style of the receive
specifications, and I would like to see this as an EEP :)

- Joe
https://cs.kent.ac.uk/~jrh53