David Barbour
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/