Re: [Haskell-cafe] Instances for continuation-based FRP

Conal Elliott wrote: > I first tried an imperative push-based FRP in 1998, and I had exactly > the same experience as Heinrich mentions. The toughest two aspects of > imperative implementation were sharing and event merge/union/mappend. This is exactly why I chose not to follow the imperative pa

Re: [Haskell-cafe] Instances for continuation-based FRP

The intuition intrigues me. If, upon inspection, it survives morphs into something else, I'd like to hear about it. Good luck! -- Conal "The object of mathematical rigor is to sanction and legitimize the conquests of intuition, and there was never any other object for it." - Jacques Hadamard "I

Re: [Haskell-cafe] Instances for continuation-based FRP

Hi Jared, Oh -- does Elm have a denotational semantics? I haven't heard of one. I just now skimmed the informal description of the Signal type, and from the reference to "updates" in the description of "merge", it sound like whatever semantics it might h

Re: [Haskell-cafe] Instances for continuation-based FRP

If you are not looking for the full reactive formalism but to treat event driven applications in a procedural ,sequential, imperative way (whatever you may call it) by means o continuations, then this is a good paper in the context of web applications: inverting back the inversion of control htt

Re: [Haskell-cafe] Instances for continuation-based FRP

Hi Hans. I'm delighted to hear that you have a precise denotation to define correctness of your implementation. So much of what gets called "FRP" these days abandons any denotational foundation, as well as continuous time, which have always been the two key properties of FRP

Re: [Haskell-cafe] Instances for continuation-based FRP

Hi Conal, Thank you for replying. My aim is to find the simplest possible implementation of the semantics you describe in Push-pull FRP, so the denotational semantics are already in place. I guess what I am looking for is a simple translation of a denotational program into an imperative one. M

Re: [Haskell-cafe] Instances for continuation-based FRP

Hi Hans, Do you have a denotation for your representation (a specification for your implementation)? If so, it will likely guide you to exactly the right type class instances, via the principle of type class morphisms(TCMs). If you don't have a denota

[Haskell-cafe] Instances for continuation-based FRP

Hi everyone, I am experimenting with various implementation styles for classical FRP. My current thoughts are on a continuation-style push implementation, which can be summarized as follows. > newtype EventT m r a= E { runE :: (a -> m r) -> m r -> m r } > newtype ReactiveT m r a = R { runR