Functional Reactive Programming, Refactored, Questions :)

[madjestic]

Hey guys,

I really enjoyed reading the paper, thank you Ivan, Manuel and Henrik so much!

The paper has addressed a lot of questions that I had in regards to dunai in specifics and FRP topic in general, I've got a few questions left though:

1. In the very end in section 10,p. 12 you wrote:

Finally, we are currently exploring the addition of clock infor-
mation to MSFs to express the speed at which asynchronous MSFs
produce and consume data, and how to coordinate them precisely.

I wonder how is this going? Looking at dunai on hackage I can see Data.MonadicStreamFunction.Async which does not have much at the moment. Is there anything else I should look at?

2. In section 7.2, p.10 you wrote:

With non-commutative monads like IO, additional measures
must be taken to ensure referential transparency at the same con-
ceptual time. If several signals depend on, for example, mousePos,
the mouse position might be sampled twice, with different results
at the same conceptual time. This can be addressed with a monad
that caches results and enables garbage collection

This is a topic that I am very interested in to know more about. Could you elaborate or give some hints and/or references?

Thanks,
Vlad

[ivanperez-keera]

Hi Vlad,

Thanks for your nice words :) Glad you liked the paper.

Regarding 1, check out https://dl.acm.org/doi/10.1145/3299711.3242757 and https://github.com/turion/rhine/.

Regarding 2, I think the simplest way to think of it is to think of an MSF l :: MSF IO () String that, at every sample, reads a line from stdin and provides that value.

Then the following happens:

msf = proc () -> do
  x <- l -< ()
  return (x, x)

is not the same as :

msf = proc () -> do
  x <- l -< ()
  y <- l -< ()
  return (x, y)

If l was a pure SF, then they would be the same, but because l is not really pure, then evaluating it twice does not render the exact same result.

Now, imagine that you define a monad like the following (assume all the necessary instances are defined):

data MyMonad a = MyMonad (Maybe String -> IO (a, Maybe String))

with an additional action:

readLine :: MyMonad String

that only reads a new string from the terminal if none is already available in the incoming Maybe String.

You could now define l as:

l :: MSF MyMonad () String
l = constM readLine

and that would make

msf = proc () -> do
  x <- l -< ()
  return (x, x)

and:

msf = proc () -> do
  x <- l -< ()
  y <- l -< ()
  return (x, y)

equivalent.

[madjestic]

Hey, Ivan

I've been trying to apply your answer to my use-case and I don't think it quite clicks yet. I would like to cache the mouse input state, in order to reduce the amount of events/sampling that are dependent on mouse state change.

Here's what it looks like so far:

...
  animate
    window
    (parseWinInput res' >>> mainLoop app &&& handleExit)
  return ()
...
parseWinInput :: (Int, Int) -> SF (Event SDL.EventPayload) AppInput
parseWinInput res =
  proc input -> do
    result <- accumHoldBy nextAppInput (initAppInput res) -< input
    returnA -< result
...
-- | mouse movement/position
nextAppInput :: AppInput -> SDL.EventPayload -> AppInput
nextAppInput inp (SDL.MouseMotionEvent ev) =
  inp { inpMouseMoving  = Just (fromIntegral x', fromIntegral y')
      , inpMouseStopped = False
      , inpMousePos     = (fromIntegral x, fromIntegral y)
      , inpMouseRelPos  = (fromIntegral x', fromIntegral y')
      }
  --where (P (V2 x  y ))  = SDL.mouseMotionEventPos ev
  where (P (V2 x  y ))  = SDL.mouseMotionEventPos ev
        (  (V2 x' y'))  = SDL.mouseMotionEventRelMotion ev
...

Should the caching occur inside parseWinInput? Does it mean that I basically should wrap accumHoldBy nextAppInput (initAppInput res) in a monad, or use a library like memo to do it? Do you know of any concrete code example that is implementing input caching in practice? I am afraid I need a more hands-on example to put this two plus two together, I am sorry.

Best regards,
Vlad

[madjestic]

Thanks, Ivan!

I've just finished reading the Rihine paper. Another great read! The advertised functionality, the benefits and structure are all top notch, but, man, those type-sigs!:

Synchronous :: ( cl ~ In cl, cl ~ Out cl) => ClSF m cl a b -> SN m cl a b
Sequential  :: SN m clab a b -> ResBuf m (Out clab) (In clcd) b c -> SN m clcd c d -> SN m (SeqClock m clab clcd) a d
Parallel    :: SN m cl1 a b -> SN m cl2 a b -> SN m (ParClock m cl1 cl2) a b

The library certainly fulfills the shopping list for the space simulator that I've been working on in terms of asynchronicity, clocks at various refresh rates, parallelism, that all sounds so tasty! The types look scary though, I would like to see how it is in practice when I will be rewriting the project inline with some ideas presented in Rhine, to see what are the practical implications and if generating type-sigs might get in the way. I did have similar concerns back in the days when looking at Yampa for the first time, but now it does not look so scary any more. Perhaps developing a Stockholm syndrome won't take too long.

Thanks again,
Vlad