Higher order receieve anybody

Joe Armstrong joe@REDACTED
Tue Feb 17 10:10:31 CET 2004

I've just been reading the discussion 
"Re: plain_fsm - for beginners and purists" 

and read the following:

> > Okay, what about
> >
> > receive
> >     .... %% normal clauses
> >     Msg ->
> >         plain_fsm:handle(State, Msg,
> > Fun_that_handles_non_system_messages)
> > end;
> >
> > It's a little ugly, but maybe not too much.

What Uffe and Vlad *really* need is a "higher order" receives ...

The idea is to rewrite:

	   {a, X} -> ...
	   b -> 
	   Y -> ...


	F = fun({a,X}) -> ...	
	       (b) -> ...
	       (Y) -> ...
	Z = receive F,

If we introduce an infix ? operator, we'd get:

	Z = ?F

Why is it not like this today? - Answer: a historical accident.

To begin with we had only first order functions, both functions
and receive patterns were first order.

We talked for a long time about "higher order patterns" in receives
without really understanding what this meant.

The notion of a pattern is intimately connected to the notion of an action
which must be performed when the pattern is matched - the *combination*
of a pattern and an action is expressed in the fun notation.

    Fun = fun(Pattern1) -> Actions1;
	     (Pattern2) -> Actions2;

Now receive is first order - ie it only takes fixed patterns. We write

      Pattern1 -> Actions1;
      Pattern2 -> Actions2;

This is very near but not quite the syntax of a Fun - so why not be consistent
and add higher order receive patterns, thus

     fun(Pattern1) -> Actions1;
        (Pattern2) -> Actions2;

Then receive becomes higher order and we can write

   Fun = fun(Pattern1) -> Actions1;
	    (Pattern2) -> Actions2
   receive Fun

and Uffe's plain_fsm becomes a simple higher order function.


So now all I'd like in Erlang is:

1) Higher order code
2) *Proper* structs
3) !!
4) Higher order receive
5) A *tiny* implementation (written 99% in Erlang and 1% in ANSI standard C)

More information about the erlang-questions mailing list