[Haskell-cafe] A question about causality in FRP
es at ertes.de
Fri Oct 14 12:07:31 CEST 2011
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
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
nightmare = unsafePerformIO (getWrongWife >>= sex)
More information about the Haskell-Cafe