Ryan Ingram ryani.spam at gmail.com
Sat Sep 29 01:58:13 EDT 2007

```I'm deriving an FRP implementation based on the ideas presented in the
understanding of arrows, but I have a couple of questions.

I'm using the following declaration for SF:

> type DTime = Double
> newtype SF a b = SF { runSF :: DTime -> a -> (b, SF a b) }

which I make an arrow in the obvious way:

> instance Arrow SF where
>     arr f = SF sf where
>         sf dt b = (f b, SF sf)
>     bc >>> cd = SF sf where
>         sf dt b = (d, bc' >>> cd') where
>             (c, bc') = runSF bc dt b
>             (d, cd') = runSF cd dt c
>     first bc = SF sf where
>         sf dt ~(b,d) = ((c,d), sfFirst bc') where
>             (c, bc') = runSF bc dt b

One question I had was about the implementation of "first".  Is it
important that the pair match be lazy?  Or is it safe to make it

My other question had to do with ArrowChoice.

> instance ArrowChoice SF where
>     left bc = SF sf where
>         sf dt (Right d) = (Right d, left bc)
>         sf dt (Left b) = (Left c, left bc') where
>             (c, bc') = runSF bc dt b

What happens to the dt in the "Right d" case?  It seems to be
invisible to the inner signal function.  Is this the right thing to
do?

I have an alternate implementation which does the following:

>         sf dt (Right d) = (Right d, left \$ addtime dt bc)

> addtime :: DTime -> SF a b -> SF a b
>    sf' dt a = runSF sf (dt + add) a

but there's a pretty clear space leak here with repeated "Right"
calls, and I'm not sure if the inner signal should see the lost time
or not.

Perhaps signal functions shouldn't be an instance of ArrowChoice at all?

Any insights would be appreciated.

-- ryan
```