Higher order receieve anybody

[Robert Virding]

----- Original Message ----- 
From: "Joe Armstrong" <joe@REDACTED>
To: <erlang-questions@REDACTED>
Sent: Tuesday, February 17, 2004 10:10 AM
Subject: Higher order receieve anybody


> 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

I think this would be a very good idea, and quite easy to implement as well.
Though there area few potentially difficult points. If I understand what you
mean then for

receive F end

you would evaluate F for each message in the queue with the message as
argument. If the function returns a value then that message is "received"
and receive returns the function return value. If the functions exits then
the message is put back in the queue and we go to the next message. Simple.

A few points:

1. Syntactically you still want receive ... end, the syntax of catch was a
big mistake so don't repeat it. We don't need more operators.
2. Timeouts would not be handled within the fun but instead have
    receive F after ... end
as before. Having timeouts in the fun would be difficult to define, explain
and implement.
3. You wouldn't need to implement this by expanding the fun, you would call
it every time.

Now for the really tough bit. Semantically this is a nightmare when you
really look into it. You get exactly the same problems as for evaluating
user defined functions in a guard. A simple example, what happens if you d
receive in the receive fun, where do you start in the message queue and
where do you stop? Choosing and extracting the message is "guard like" and
within it it is difficult to handle user functions.

OK, you could say that you handle just just the clause selection bit of the
fun as the message selection part and then handle the rhs as the rhs of the
fun. This is difficult as the fun was meant to be a general fun and not
specially compled. Well set a flag and test at commit time, easy. I think
the current compiler has done away with commit, there is no need for.

My point is that when you really delve into it it becomes difficult in most
respects. Sorry to be a wouser.

> 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)

Definitely yes to 1,2 and 5. I don't really see the point of having !!, if I
understand it correctly it is just syntactic sugar so why bother. How about
replacing ! with erlang:send/2?

Robert