[erlisp-devel] receiving, pattern-matching
Dirk Gerrits
dirk at dirkgerrits.com
Mon Aug 29 17:35:29 UTC 2005
Eric Lavigne wrote:
> How does receive work? I see that one of the arguments is a pattern
> for indicating what sort of message I am interested in, but I don't
> understand how to write/interpret such a pattern.
Depends on the matcher used. Erlisp currently only has COND and CASE
based matcher, which are very lame. See test/matcher.lisp and
test/messaging.lisp for examples.
It should be easy to write support for fare-matcher (or whatever matcher
you want) though.
> Also, will I receive only the first message that matches this pattern?
Yep. To process all matching messages you do RECEIVE with a 0 timeout
in a loop, and make the timeout clause end the loop.
> What happens if no messages match the pattern? Returns nil
> immediately? Block until such a message arrives?
Block until such a message arrives, or the timeout is reached (if one is
specified).
> Specifically, I would like to send a list as a message and recognize
> the message type based on the first element.
> Example (recognize that this starts with 'system):
> (list 'system 'link-request 'notify)
> I would like to receive the first message from the mailbox in
> *current-process* whose first element is 'system, returning
> immediately in the case where no such message is found. How could I
> set up a pattern-matcher for this? Can I use receive? Or will I need
> to use receive-with-timeout and a short time limit?
This should do the trick, though I can't test it before I get back to my
laptop in a couple of hours:
(receive-with-matcher (cond-matcher m)
((and (consp m) (eq (car m) 'system))
...)
((:timeout 0)
nil))
> Better still, is there a way to set up a default handler that would
> perform predefined action whenever a message matching its pattern
> shows up?
There is not. Could you define "whenever a message matching its pattern
shows up" exactly? Would it be as if every RECEIVE has additional
invisible clauses above the explicitly written ones?
> If so, I would like to use this. If not, I think it would be worth
> adding later. I can imagine writing an entire program made up
> entirely of default handlers for various message patterns.
Doesn't seem very Erlangy to me, but that's not the purpose of Erlisp
anyway. ;) If you can demonstrate to me why this would be an advantage
and how we could implement it, then I'm all for it, but at the moment I
can see neither.
- Dirk
More information about the Erlisp-devel
mailing list