[Haskell-cafe] A question about causality in FRP

[Ertugrul Soeylemez]

David Barbour <dmbarbour at gmail.com> wrote:

> > The usual model for arrowized FRP is based on this type:
> >
> >    newtype Auto a b = Auto (a -> (b, Auto a b))
> >
> > I would be very interested in how you would write an ArrowApply
> > instance for such a type.  So far my conclusion is:  It's
> > impossible.
>
> Interesting claim. The implementation is obvious enough:
>   runAuto (Auto f) = f
>   app = Auto $ \ (f,x) -> let (x',f') = runAuto f x in (x',app)
>
> Which arrow laws does this violate? Or is your concern that a fresh
> arrow supplied to `app` at each instant obviously cannot accumulate
> state?

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


> Yampa AFRP model chooses to model products using the `Either` type -
> i.e.  indicating that either element can be updated independently.
> Using this, one could accumulate state in the captured arrow, though
> there'd be a funky reset whenever the arrow is updated.

Of course you can make a trade-off, but I don't think it's possible to
solve this in a clean way in the automaton model.


> 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?


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/