Higher order receieve anybody

[Joe Armstrong]

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:

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

as

	F = fun({a,X}) -> ...	
	       (b) -> ...
	       (Y) -> ...
	    end,
	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;
	     ...
	  end.

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

   receive
      Pattern1 -> Actions1;
      Pattern2 -> Actions2;
      ...
   end

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

   receive
     fun(Pattern1) -> Actions1;
        (Pattern2) -> Actions2;
	...
     end.

Then receive becomes higher order and we can write

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

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

   /Joe

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)