[erlang-questions] eep: multiple patterns

[Ulf Wiger]

Thanks, Richard. Very good observations.

2008/6/4 Richard A. O'Keefe <ok@REDACTED>:
>
> On 30 May 2008, at 8:25 pm, Ulf Wiger (TN/EAB) wrote:

> Instead I'll comment on something else.
> I appreciate why things like
>
>        {distr_msg, DistrMsgId, ?HCMSG_REMOVE_HC} ->
>
> exist.  I appreciate how the use of suitable names here can
> make it easier to figure out the intention of the code.
> However, as soon as you have things like
>        {a, B, ?C} ->
>       ; {a, B, ?D} ->
>       ; ...
> you discover that you cannot tell whether these patterns
> overlap without manually expanding the macros.

Indeed. It would perhaps be good to use a type naming
convention, similar to that used in the erts sources (e.g.  AM_TRUE,
to signify the atom 'true'.) The best thing would be to do without
the macros, and use abstract patterns instead (which, in a sense,
is what the macros are in this case - albeit pretty bad ones.)

A historical reason for this use of macros is that it gives you
a form of simple spell check. Whereas a pattern using the
atom 'flase' (common typo) might well go undetected, a misspelt
macro reference gives a compile-time error.

With dialyzer, many of the reasons for doing this go away, but
dialyzer will not detect typos in receive patterns.


> In an earlier message in this thread I suggested that a tool
> that warns you of 'critical' pairs in receive, case, or
> function heads would be useful.  For getting code of this
> level of complexity right, I must raise that to EXTREMELY
> useful.

Yes!


> One of
> the things that struck me when trying to read other people's
> Erlang was that I could tell without enormous trouble (because
> I hadn't seen the system Ulf Wiger was talking about!) what
> messages processes DID receive, but it was very much harder
> to tell what messages they SHOULD receive.

Yes.

This is actually a very strong argument against structuring large
systems using message-passing interfaces, even though that
might seem quite the natural thing to do in Erlang. Using function
interfaces, the compiler, xref, dialyzer et al can give you lots of
help, but with message passing no tool support can help you
figure out (1) whether the message you send is properly formatted,
or (2) how to jump to the place in the code where the message is
handled.

The bigger the system, the more terrible this problem becomes.


>
> There were two ways I thought of using abstract patterns
> for this.
> (1) As executable message filters.  A process would be able
> to install an abstract pattern as its filter, and any message
> sent to it that _didn't_ match the filter would automatically
> be discarded at once.
> (2) As possibly-executable annotations.
>
>        #protocol() receive
>            Pattern1 when Guard1 -> Action1
>          ; ...
>        end

This would be very useful, I think.

> Another thing that occurs to me with an example of this size
> and complexity is that perhaps some 'little language' could
> be used for specifying separate pieces and then weaving them
> together.

Yes, perhaps, but I'd like to see how far we could come using
abstract patterns first.  (:

BR,
Ulf W