"Unapplying" signals?

[Manuel Simoni]

In my trivial RDP impl [1] you apply a signal like this to a behavior, yielding an output signal:

    var sigOut = rdp.apply(behavior, sigIn);

The behavior must install a listener that gets updated when the input signal changes.

Even when input signal becomes inactive, the listener must remain installed, in case the signal becomes active again.

I wonder if there's a need for a way to unapply a signal -- i.e. to completely break the association between the behavior and the input signal?

--Manuel

[1] https://github.com/manuel/bucky-rdp

[David Barbour]

Dynamic behaviors model this sort of 'unapply'. I modeled this in Sirea [1] (docs). In a few words: we have a signal that carries behaviors/programs that we install and uninstall over time.

[1] https://github.com/dmbarbour/Sirea/blob/master/src/Sirea/Behavior.hs#L576

Sirea also distinguishes normal algebraic sum types (a+b), aka `Either a b`, from signal-layer sums (a :+: b). This makes it a lot simpler to disable large subnets, with behavior switching from the left subnet to the right subnet. This can feasibly be implemented using an install/uninstall technique, though Sirea did not use that technique.

As an aside: these days I'm looking more into reactive (temporal) extensions for Kahn Process Networks [2], which have the nice features of being 'monotonic' and incremental. I was initially developing this as a possible substrate for RDP in purely functional programming. But it seems reactive process networks might prove the superior model overall for developing large scale reactive, incremental systems. KPNs make interesting first-class 'object' values with distributed background parallelism, and a more expressive and composable effects model compared to monads.

[2] https://awelonblue.wordpress.com/2016/11/23/reactive-process-networks/

Also, it's good to hear from you again, Manuel.

-- Dave

[Manuel Simoni]

I've read your blog posts on KPNs [1,2], but it's unclear to me how they fit into the intended application area of RDP (i.e. composition and orchestration of interactive open systems). 

KPNs look just like one-way data transformers to me. How would you model temporal coupling? Maybe you could give some examples? 

[1] https://awelonblue.wordpress.com/2016/09/29/kpns-as-an-effects-model/

[2] https://awelonblue.wordpress.com/2016/11/23/reactive-process-networks/

[David Barbour]

What KPNs offer is a computation model that is scalable, incremental, and flexibly compositional. But a lot of other properties - such as integration of resources and services in open systems - would be left to development and integration of an effects model.  

KPNs are more flexible than RDP. If one needs RDP's guarantees like temporal coupling and easy detachment of a process from the environment, one could compile from RDP down to a KPN for distributed computation. That is, the KPN layer would be how I translate from RDP's effects model to an incremental, distributed message-passing system. This is what I meant earlier by "a possible substrate for RDP" - using KPNs as a compilation target. 

But, KPNs are deterministic (up to effects), and they're first-class values (subject to serialization, persistence, checkpointing, wrapper patterns, etc..). Between those properties, much of the challenge surrounding development and debugging of large scale distributed programming is mitigated. I imagine that if people developed systems using KPNs, they wouldn't feel need for temporal coupling to simplify resource management. 

So it isn't that KPNs directly subsume RDP, but rather that they solve enough of the big problems that learning the RDP paradigm and working with RDP constraints would have dubious utility.  That said, using RDP ideas to help guide development of an effects model seems like a useful idea.

--
You received this message because you are subscribed to the Google Groups "reactive-demand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactive-demand+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.