On Fri, Oct 14, 2011 at 3:07 AM, Ertugrul Soeylemez <e...@ertes.de> wrote:
> 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-rdp/
My code is on github, but I still break it on a regular basis.
Regards,
Dave
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
