Discussion:
Signals / Messages / Events / ...?
Christopher Howard
2018-01-03 05:09:19 UTC
Permalink
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?
--
http://upgradefromwindows.com
Neil Jerram
2018-01-03 11:53:33 UTC
Permalink
Post by Christopher Howard
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
Christopher Howard
2018-01-03 15:11:20 UTC
Permalink
Well, one Lispy mechanism in that area is hooks.  For example, from
some 
;; 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
I think that should work. Only part I'm not sure about is if you can
have a "one-off" procedure added to a hook... but you could just have
the procedure call remove-hook! to remove itself...?
--
https://www.debian.org/
Neil Jerram
2018-01-03 19:53:28 UTC
Permalink
Post by Christopher Howard
Post by Neil Jerram
Well, one Lispy mechanism in that area is hooks.  For example, from some
;; 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
I think that should work. Only part I'm not sure about is if you can
have a "one-off" procedure added to a hook... but you could just have
the procedure call remove-hook! to remove itself...?
Yes, I think so, and you could encapsulate that with something like this:

(define (add-hook-once-only! hook proc)
  (letrec ((proc-once-only
            (lambda args
              (remove-hook! hook proc-once-only)
              (apply proc args))))
    (add-hook! hook proc-once-only)))

Best wishes - Neil
Matt Wette
2018-01-04 01:16:54 UTC
Permalink
Post by Christopher Howard
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?
--
http://upgradefromwindows.com
If you are on Linux you can look at fibers:
https://github.com/wingo/fibers <https://github.com/wingo/fibers>

it is lightweight processes with message passing.

Loading...