David Barbour <dmbarb...@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/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
