[Haskell-cafe] A question about causality in FRP

David Barbour dmbarbour at gmail.com
Fri Oct 14 18:01:33 CEST 2011


On Fri, Oct 14, 2011 at 3:07 AM, Ertugrul Soeylemez <es at ertes.de> wrote:

> It's not about the laws, it's about losing state.
>

I think you should not accumulate state; the abstraction gives me a fresh
arrow each instant, conceptually and pragmatically. But it would not be
difficult to create an abstraction specifically for dynamic, stateful
accumulators.

class (Arrow a) => ArrowAppS a where
  apps :: st -> a (a (x,st) (y,st), x) y

instance ArrowAppS Auto where
  apps s0 = Auto $ \ (f,x) ->
    let ((y,sf),f') = runAuto f (x,s0) in
    (y,apps sf)


>
> > The reactive model I'm developing, Reactive Demand Programming, is
> > actually anti-causal: behavior at any given instant may depend only
> > upon its present and future inputs (anticipation), but never the
> > past. State is treated as an external service, part of an abstract
> > machine, orchestration of registers or a database. I think this setup
> > works better than FRP, e.g. for controlling space-leaks, supporting
> > smooth transitions and upgrades of dynamic behavior, modeling the app
> > as a whole as dynamic, and orthogonal persistence.
>
> I would be very interested in such a model.  Are there any resources
> online?
>

Just my blog. Here are a few select articles:
* http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/
* http://awelonblue.wordpress.com/2011/05/28/anticipation-in-rdp/
*
http://awelonblue.wordpress.com/2011/08/26/demand-monitors-heart-and-soul-rdp/


My code is on github, but I still break it on a regular basis.

Regards,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111014/cff7ca75/attachment.htm>


More information about the Haskell-Cafe mailing list