Higher order receieve anybody

Ulf Wiger ulf.wiger@REDACTED
Tue Feb 17 10:42:30 CET 2004


On Tue, 17 Feb 2004 10:10:31 +0100 (CET), Joe Armstrong <joe@REDACTED> 
wrote:


> 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

My first (*) version looked like this:

idle(S) ->
    plain_fsm:recv(
       fun({a, x}) -> ...;
          (b) -> ....
          (Y) -> ...
       end).

(*) in this iteration; I've attacked the problem a number of times
over the past years.

This happens to be quite similar to what you propose, except
of course that you propose a language change, while my hack
was just a way to trigger the parse_transform.

I changed it to

  plain_fsm:extended_receive(
    receive
        ...
    end)

because it was easier to introduce into legacy code.

3.5 years ago, I had the idea that one should be able
to extend the receive semantics using some "system directive"
(disregard the syntax):

$extend_receive(system_receive) ->
    receive
       {system, From, Msg} ->
          sys:handle_system_messages(...);
       $receive()
    end.

But with Joe's suggestion, no keyword redefinition or
parse_transform is needed.

(I also imagined the directives $inherit_api(FromModule) and
$fast_path(Function, Arity) -> hard | {slow_path, fun()}
(where 'hard' indicates EXIT if the fast-path code throws an
exception; and {slow_path, F} means, exit and run F instead.))

/Uffe
-- 
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.




More information about the erlang-questions mailing list