[Haskell-cafe] Instances for continuation-based FRP

Conal Elliott conal at conal.net
Fri Apr 26 00:40:59 CEST 2013


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.

-- Conal


On Thu, Apr 25, 2013 at 5:16 AM, Heinrich Apfelmus <
apfelmus at quantentunnel.de> wrote:

> Hans Höglund wrote:
>
>> 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.
>>
>
> In reactive-banana, the Reactive.Banana.Model module implements /
> defines the denotational semantics.
>
>   http://tinyurl.com/Reactive-**Banana-Model<http://tinyurl.com/Reactive-Banana-Model>
>
> It's very similar to Conal's semantics from the Push-Pull article.
>
>
>  I guess what I am looking for is a
>> simple translation of a denotational program into an imperative one.
>> My intuition tells me that such a translation is possible, maybe even
>> trivial, but I am not sure how to reason about correctness.
>>
>
> In my experience, the main problem with imperative implementations is
> that they have a hard time with the  union  combinator and with
> preserving sharing. Reactive-banana is the best I could come up with.
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
>
>
> ______________________________**_________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130425/964e2811/attachment.htm>


More information about the Haskell-Cafe mailing list