Higher order receieve anybody
Joe Armstrong
<>
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:
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)
More information about the erlang-questions
mailing list