Higher order receieve anybody

[Ulf Wiger]

On Mon, 23 Feb 2004 23:42:00 -0800 (PST), Thomas Lindgren 
<thomasl_erlang@REDACTED> wrote:

>
> --- Robert Virding <robert.virding@REDACTED> wrote:
>> That would probably be a cleaner way of doing it.
>> Though it would be a little tricky to handle timeouts.
>> I can't see that there would be real problems with it,
>> though I will have to think abit.
>>
>> How much oomph do you want?
>
> Personally, I'm not convinced receive needs much
> beyond what we already have. Messing around with
> mailboxes (as I proposed) sounds like a typical "under
> the hood" issue. (Or are there cases where this is a
> huge help to the programmer? It might come in handy
> for erlang-in-erlang, but for application
> programmers?)

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.

/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.