[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Signals / Messages / Events / ...?

From: Neil Jerram
Subject: Re: Signals / Messages / Events / ...?
Date: Wed, 3 Jan 2018 11:53:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 03/01/18 05:09, Christopher Howard wrote:
Hi list, forgive me if this is a somewhat vague question... but is
there some kind of framework/system/approach for Guile where you could
have different parts of your code register callback functions to react
to a certain signal or message raised by any other part of the code?
I'm thinking like dbus where I guess you can sort of send off a message
but not really care who receives it. In chickadee you can register
callbacks for the various input events, and i think that basic idea
could be extended so long as (1) you could have any kind of
event/signal you wanted; (2) call backs added could be specified as
either persistent or one-time call-backs.

It seems like it wouldn't be too hard to code something like that with
just lists of callback functions tied to names/data in a tree. But
maybe somebody has already thought of that or would suggest a better

Just running into this challenge in development where a function like
"new-game" has to do 8 different things to 6 different data structures,
but why not instead just have the code dealing with the 6 different
objects register callbacks to receive the 'new-game signal? I think
message passing is the wrong term because in message passing you
specify the message connections between the different objects, right?
Signal bus maybe?

Well, one Lispy mechanism in that area is hooks.  For example, from some of my old code:

;; Changes to modem registration state are indicated by calling this
;; hook with args STATE and PROPERTIES.  STATE can be 'none, meaning
;; that there is currently no modem; 'unregistered, meaning that there
;; is a modem but it isn't registered with the network; or
;; 'registered, meaning that the modem is registered with the network.
;; If STATE is 'registered, PROPERTIES is an alist of registration
;; properties; otherwise PROPERTIES is #f.
(define registration-hook (make-hook 2))

(define (add-registration-hook proc)
  (add-hook! registration-hook proc))

(define (notify-registration state properties)
  (run-hook registration-hook state properties))

Does that serve your purpose at all?

Best wishes - Neil

reply via email to

[Prev in Thread] Current Thread [Next in Thread]