`Behavior` constantly re-evaluating when caching is expected about reactive-banana HOT 4 OPEN

I also note that if I don't have reactimate $ print <$> b' <@ onPrint then I don't get a sampling message at all. This surprises me, because [Note LatchStrictness] states that all latches (and thus I would expect all Behaviors) should be in WHNF at the end of network evaluation - but that doesn't seem to actually be happening.

from reactive-banana.

A smaller repro:

{-# language BlockArguments #-}

module Main where

import Data.Functor
import Debug.Trace
import Reactive.Banana
import Reactive.Banana.Frameworks

main :: IO ()
main = do
  (onChangeCheckbox, changeCheckbox) <- newAddHandler

  actuate =<< compile do
    onToggle <- fromAddHandler onChangeCheckbox
    checked  <- stepper False onToggle

    let b1 = traceShowId <$> pure "1"
    let b' = liftA2 (,) checked b1

    reactimate $ return () <$ b' <@ onToggle

  changeCheckbox True
  changeCheckbox False
  changeCheckbox True

Note that changing b1 to be b1 = pure $ traceShowId "1" there is no problem. Also, changing b' to be let b' = traceShowId <$> pure 1 <* checked also doesn't have a problem. It seems to be something specific about having a separate b1 binding that uses fmap.

I also tried let b' = b1 <* checked and this also doesn't have the problem

from reactive-banana.

Another weird point: let b' = liftA2 (,) b1 checked does not have a problem, but let b' = liftA2 (,) checked b1 does. So the order here seems to matter. Probably need to get into core at this point.

from reactive-banana.

I made some progress on understanding this one.

Here's a rough diagram of a slightly simplified version of Ollie's example.

The black text are latches, with nodes in the tree being <*> pointing at the left and right side.

The red arrow shows an onToggle event coming in and affecting the value of the checked latch directly.

We need to calculate the value of the entire latch (the root of the tree), so we will go down depth-first, getting each latch's value, per the definition of applyL and cachedLatch:

So, say the event occurs at time t=5. When evaluating the whole latch, after getting to the checked child, we'll write t=5 to the evaluation context, since it was directly updated by the event. (The EvalL monad is WriterT Time IO; the time indicates the latest time that this evaluation is recent as of).

Then, later nodes in the tree (such as our traceShowId <$> pure "1", which we expect to be unaffected by the onToggle event and thus not recomputed, enter the same evaluation logic

only in a context where t=5 is already written to the EvalL context. We'll therefore hit the else-branch which corresponds to recomputing this value rather than using what's cached.

from reactive-banana.