Signals / Messages / Events / ...?

Signals / Messages / Events / ...?

[Christopher Howard]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Neil Jerram]

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

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

[Christopher Howard]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

On Wed, 2018-01-03 at 11:53 +0000, Neil Jerram wrote:
> 
> 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
> 
> 

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/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Neil Jerram]

On 03/01/18 15:11, Christopher Howard wrote:
> On Wed, 2018-01-03 at 11:53 +0000, Neil Jerram wrote:
>> 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
>>
>>
> 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

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

[Matt Wette]

> On Jan 2, 2018, at 9:09 PM, Christopher Howard <christopher.howard@qlfiles.net> 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?
> 
> -- 
> 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.