[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