[erlang-questions] eep: multiple patterns

[Richard A. O'Keefe]

On 28 May 2008, at 7:41 pm, Ulf Wiger (TN/EAB) wrote:
> I would just like to point out, for the record, that
> this style of programming works well for gen_server-style
> processes (and is, in fact, used in e.g. gen_server.erl),
> but for selective receive, it is much harder, since
> selective receive relies entirely on pattern matching,
> and as such, is very difficult to modularize.

It's not completely clear to me what Ulf Wiger means by
"this style of programming".  Using "this style of
programming" to mean "the decision table pattern",
it works perfectly fine for selective receive.

	case receive			% DECISIONS!
		P1 when G1 -> A1
	      ; P2 when G2 -> A2
	      ...
	      ; Pn when Gn -> An
	      after T -> A0
	    end
	 of A1 ->			% ACTIONS!
	      B1
	  ; A2 ->
	      B2
	  ...
	  ; An ->
	      Bn
	  ; A0 ->
	      B0
	end

Indeed, I've always assumed that receives were actually
implemented that way under the covers and never bothered
to look.  Here the A1 are either atomic tags or
{tag,Datum,...} tuples naming what each pattern *means*.

Let's be clear here:  *most* of the time you shouldn't do
this, and if you find that you want to, you should first
think hard about refactoring your message protocol, even
to the extent of hiding behind a proxy process that
converts a messy protocol to a clean one (and has no other
tasks).  Having several patterns that map to the same thing
is a good sign that your information representation is
flawed.

One tool that would be nice to have, and perhaps the
Dialyzer already does this, is something that tells you
when the clauses of a function or of a case or of a
receive overlap.  In classic pattern-matching terminology,
I'm talking about "critical pairs", and they are critical
for programming reliability because they are the ones
where the order of the clauses matters for correctness.
Interleaving patterns and actions makes it harder to
visually compare the patterns to check for critical
pairs, omissions, &c; separating them makes it easier.

> At the risk of starting to sound like a broken record,
> I'd very much like to see suggestions that don't further
> encourage programmers to use gen_server-style programming
> where they really ought to be writing selective receive
> clauses (textbook erlang state machines). There is already
> a tendency to do this, as gen_server* gives you a lot of
> stuff for free - handling of system messages, a consistent
> way of reporting programming errors, etc.

Since the decision table pattern is fully compatible with
selective receive, I don't see the relevance of this point
to this thread.

> For that reason, suggestions that allow for parameterized
> guards, e.g. in selective receive, are much more attractive
> than those that don't.

I don't understand what "parameterized guards" means here.
This is a thread about multi-PATTERNS, not guards as such.