From: Neil Jerram <neil@ossau.homelinux.net>
To: guile-user@gnu.org
Subject: Re: Signals / Messages / Events / ...?
Date: Wed, 3 Jan 2018 11:53:33 +0000 [thread overview]
Message-ID: <f2992b7b-a4aa-516e-7365-17f3b292e711@ossau.homelinux.net> (raw)
In-Reply-To: <1514956159.4049.2.camel@qlfiles.net>
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
> approach.
>
> 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
next prev parent reply other threads:[~2018-01-03 11:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 5:09 Signals / Messages / Events / ...? Christopher Howard
2018-01-03 11:53 ` Neil Jerram [this message]
2018-01-03 15:11 ` Christopher Howard
2018-01-03 19:53 ` Neil Jerram
2018-01-04 1:16 ` Matt Wette
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2992b7b-a4aa-516e-7365-17f3b292e711@ossau.homelinux.net \
--to=neil@ossau.homelinux.net \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).