[Haskell-cafe] Is Arrow based FRP a subset of Classic FRP, at least conceptually/semantically?

[Luke Palmer]

On Mon, Jan 5, 2009 at 10:09 AM, Peter Verswyvelen <bugfact at gmail.com>wrote:

> Classic FRP ("CFRP", like Fran, FAL, Reactive, Grapefruit?...)
> exposes signals as first class values.
>
> Arrow based FRP ("AFRP", like Fruit, Yampa...) hides signals as first
> class values; instead the signal transformers are the first class
> values.
>
> Can I conclude that it would theoretically be possible to translate an
> AFRP function into a CFRP function? I.e. is AFRP a subset of CFRP?


Why don't you check yourself?

AFRP, if I recall correctly, has Arrow and ArrowLoop.  So the combinators we
need follow:

Using a ~> b as shorthand for Behavior a -> Behavior b.

   -- From Arrow
   arr :: (a -> b) -> (a ~> b)
   first :: (a ~> b) -> ((a,c) ~> (b,c))
   (>>>) :: (a ~> b) -> (b ~> c) -> (a ~> c)

   arr = fmap
   first f ac = liftA2 (,) (f (fst <$> ac)) (snd <$> ac)
   (>>>) = (>>>)

   -- From ArrowLoop
   loop :: ((a,c) ~> (b,c)) -> (a ~> b)
   loop f a = let bc = f (liftA2 (,) a (snd <$> bc)) in fst <$> bc

So that's a positive on all the arrow combinators.  You have to check the
supplied primitives, too, such as integral and pswitch.  Once you do that,
you could even implement a ClassicFRP arrow and use that instead of the
Yampa arrow, so the client code wouldn't need to be changed at all.

What I have just described is the ideal situation.  Here are some of the
practicalities you might run into:

  * AFRP models events as signals of Maybe.  Semantically speaking, signals
of Maybe don't have nice eventy properties, such as discrete occurrences, so
you might have some difficulty translating between the two.  I'm currently
exploring an arrow model that accounts for events properly, but that
probably doesn't help you.
  * The above "loop" combinator is key to eliminating quadratic behavior in
certain classic FRP situations, and I believe the reason arrows were
explored to begin with.  See "Plugging a Space Leak with an Arrow" by Hudak
and Liu[1] for more.  In Fran-like systems, there is another fix for this
leak, in exchange for loss of perfect reactivity (making a "discrete memo
table" of sorts).

[1] www.cs.yale.edu/~hl293/download/*leak*.pdf<http://www.cs.yale.edu/%7Ehl293/download/leak.pdf>


>
> Thanks,
> Peter
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090105/0ae93f9e/attachment.htm