Higher order receieve anybody

[Shawn Pearce]

This is a pretty good idea.  Except that the 'system' category should
be extensible, so behaviors can add their own notion of what 'system'
is.  For example, some of my behaviors I'd like to have inspect messages
that the end-developer doesn't have to get involved in; as the behavior
offers those services to the developer.

If receive F end was possible, it might be nice to register a fun in a
process_flag, e.g. process_flag(system_message_handler, F).  When the
user application wants to accept system messages, the receive call adds
another keyword:

	receive
	system;
	... -> ...
	end.

The runtime scans the mailbox for the first message that matches either
the current receive pattern, or the fun set as the
system_message_handler.  The only issue is where do you resume execution
after the sys module has processed the message...

I think higher order receive is a lot like my "why aren't modules just
sets of variables bound to funs" question.  :)  Sure its nice and all,
but the reality is, most developers would prefer to write:

	receive
	{foo, ...} -> ...
	end

over

	receive fun({foo, ...}) -> .. end end

any day.  But it does at least allow usage like:

	plain_fsm_receive(fun({foo, ...}) -> ... end)

assuming that the higher order receive allowed multiple funs at once:

	plain_fsm_receive(F) ->
		SytemHandler = fun(...) -> ... end,
		receive SystemHandler, F end.

But then I'd have to just ask for erlang:receive([F]), as in:

	receive([SystemHandler, F]).

and say forget keywords.  The receive keyword is only nice as a
syntatic sugar form of the receive BIF and a list of 0 argument funs,
created from the body of the keyword.


One problem with system messages is how processing resumes.  In fact,
I think that is the more difficult part of this discussion; as there
is no one way to behave after a system message is processed...

Ulf Wiger <ulf.wiger@REDACTED> wrote:
> I do not see much need for application programmers messing
> around with the mailbox. There are almost always fairly
> simple workarounds in the cases where it might be warranted.
> 
> Handling system messages is the one area where I've found it
> necessary to raise the abstraction level above what 'receive'
> provides. There are workarounds -- they are called gen_server
> and gen_fsm, but they have the unfortunate side-effect of
> imposing an un-erlangish message reception paradigm on the
> unsuspecting user.
> 
> I would like to see the possibility to divide messages into
> two separate categories: administrative (such as suspend,
> resume, inspect, upgrade) and operative (whatever the program
> is _really_ supposed to do. And I would like to be able to keep
> them separated without messing up the programming semantics.

-- 
Shawn.

  	While riding in a train between London and Birmingham, a woman
  inquired of Oscar Wilde, "You don't mind if I smoke, do you?"
  	Wilde gave her a sidelong glance and replied, "I don't mind if
  you burn, madam."