On Fri, Oct 14, 2011 at 3:07 AM, Ertugrul Soeylemez
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-rd... My code is on github, but I still break it on a regular basis. Regards, Dave