[erlang-questions] eep: multiple patterns

[Ulf Wiger (TN/EAB)]

Richard A. O'Keefe skrev:
> On 28 May 2008, at 12:36 am, Andras Georgy Bekes wrote:
> 
>> OK, you asked for real-life examples. OK, simple pattern.
>> Here it is, straight from AXD301. I've replaced the "interesting"  
>> parts
>> with foo, bar and baz. Everything else is original.
> 
> GREAT!
>>
...
> 
> Cleaning it up as
>      case classify_foo(Foo)
>        of undefined ->
>           bar()
>         ; {meaningful,Bar,Baz} ->
>           baz(Bar, Baz)
>      end,
>      ...
> classify_foo(undefined        ) -> undefined;
> classify_foo({undefined, _, _}) -> undefined;
> classify_foo({Bar,     Baz, _}) -> {meaningful,Bar,Baz};
> classify_foo({Bar,     Baz}   ) -> {meaningful,Bar,BAz}.
> 
> I like it *fine*, especially if the arms of the case are
> split out as separate functions (should that be possible).

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.

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.

* gen_fsm is too semantically similar to gen_server, and
   doesn't offer selective receive any more than gen_server
   does - at least not in a way that matters much.

The problem with this is that it leads to "happy-case
programming" in a bad sense. It works fine for a large
class of cases, but when you run into situations with
interleaving events, it blows up in your face.

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

BR,
Ulf W