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