[Haskell-cafe] Arrow laws of Netwire

Ivan Perez ivanperezdominguez at gmail.com
Sun Feb 18 17:08:24 UTC 2018


On 18 February 2018 at 11:36, Oliver Charles <ollie at ocharles.org.uk> wrote:

> On Sun, Feb 18, 2018 at 9:17 AM, Ivan Perez <ivanperezdominguez at gmail.com>
> wrote:
>
>> Hi
>>
>> > However, unless you have a strong reason to use arrowized FRP I would
>> recommend that you go with one of the first-class FRP libraries.
>>
>> TL;DR: Shameless self promotion ahead: we built an elementary library
>> that seems to subsume many others, including AFRP and Classic FRP
>> libraries, I'd like to know how it compares.
>>
>> Seeing what's just been said about netwire, I'd like to ask how these
>> compare to each other. Among themselves, and also in relation to a separate
>> construct that Manuel Bärenz and I built (note: I am the Yampa maintainer;
>> Yampa is alive and well and more updates are coming your way :) ).
>>
>> In 2016 we published an article [1; mirror: 4] and a library [2] which
>> aim at merging ideas in this field. I always thought they were pretty
>> powerful, and so far I haven't found many limitations. (But I am biased, so
>> maybe not the ideal judge.)
>>
>> It combines the CPS-based arrowized construct of Yampa with a monad, in a
>> tiny definition:
>>
>> newtype MSF m a b = MSF { step :: a -> m (b, MSF m a b) }
>>
>
> I believe this is exactly what a `Wire` is from the `wires` library:
>
> https://github.com/esoeylemez/wires/blob/master/Control/Wire
> /Internal.hs#L89
>
> Ollie
>

This is great to know :)

Given then that what I said about classic FRP and many variants of FRP
should apply to wires too, how would programming in a classic FRP library
be any different from using Wires, Dunai, Varying, etc., all of which are
based on the same construct? (Performance aside.)

Ivan

[1] https://hackage.haskell.org/package/varying
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180218/395c8a03/attachment.html>


More information about the Haskell-Cafe mailing list