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

[Michael Truog]

On 06/05/2017 06:16 AM, ok@REDACTED wrote:
>>> 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.
> The problem is that right now fun() and -spec say *nothing*
> about reception.  Backwards compatibility seems to require
> not changing that.
>
> The idea was that a checker should *infer* 'receive none()'
> for pure functions, and that this should *refine* a given
> -spec.
>
> One thing I was after was that you should normally require
> just one -protocol declaration per process, with the
> receive part of the functions it calls being inferred.

I believe it is more important to be able to mark functions impure or pure within the Erlang type specification as described at https://bugs.erlang.org/browse/ERL-373 than to clarify the received messages, though it would be nice to have both.  In practice, the code paths taken with a receive won't benefit clearly with the -protocol addition, when considering how receives are normally buried in an Erlang behaviour (it is considered beneficial to use Erlang behaviours in practice, and often explicit receives are typical in academic exercises which may refer back to Erlang in earlier days before OTP existed).  If we could mark functions as impure or pure and have it inferred/checked with dialyzer, there would always be a clear benefit at any level of abstraction.