Fix matchResponseMapWithRequests to handle prompt response.

[bglgwyng]

app :: forall t m. (MonadHeadlessApp t m) => m (Event t ())
app = mdo
  ePostBuild <- getPostBuild

  rec (_, eRequest) <-
        runRequesterT
          ( do
              eX <-
                requesting (ePostBuild $> Const ())
              performEvent_ $ ffor eX (const $ liftIO $ print "Got Response!")
          )
          eResponse'
      (eRequest', eResponse') <-
        matchResponseMapWithRequests
          (\x -> (mkSome x, \case Some x -> unsafeCoerce x))
          eRequest
          eResponse
      eResponse <- pure $ ffor eRequest' $ fmap (\(Some req) -> Some (Identity 1))
  pure never

This minimal example demonstrates a request/response interaction. When a request is made, the corresponding response is generated immediately, as seen in the eResponse definition. However, the current implementation of matchResponseMapWithRequests doesn't correctly handle prompt responses, resulting in "Got Response!" not being printed from eX. This fix ensures that prompt responses are handled correctly, allowing "Got Response!" to be printed as expected.

[ryantrinkle]

Looks like a good patch, but I am slightly concerned about this being prompt. What if someone does something like this?

b <- requesting a
c <- requesting b

Will that create a cycle? It seems like it would. It would be great to add a test for this

Even if that does in fact create a cycle, we could still have something prompt here as an option

[bglgwyng]

I tried to add test for new matchResponseMapWithRequests, but after I read https://github.com/reflex-frp/reflex/blob/develop/test/RequesterT.hs#L80, I got confused about why the current matchResponseMapWithRequests has passed this test. testMatchRequestsWithResponses responses promptly also, why does the current test pass the current matchResponseMapWithRequests?

[bglgwyng]

I think we can refactor this code with ??? :: Event a -> Event b -> Event (a, Just b). Do we have something similar?

[bglgwyng]

Looks like a good patch, but I am slightly concerned about this being prompt. What if someone does something like this?

b <- requesting a
c <- requesting b

Will that create a cycle? It seems like it would. It would be great to add a test for this

Even if that does in fact create a cycle, we could still have something prompt here as an option

The example you gave hangs, not even printing 'causality loop detected.

[ali-abrar]

Closing this based on the conversation above. Please reopen if you're still interested in this.

[parenthetical]

Reopening because I'd like to investigate this some more since I'm interested in increased laziness.

[bglgwyng]

I used to need this behavior when I was trying to structure my entire Reflex project as a set of request-response relationships. That led me to implement something like this:

newtype Counter t = Counter (Behavior t Int)
data CounterReq a where
  Inc :: CounterReq ()
  Dec :: CounterReq ()

It’s been years since I last wrote Reflex code, so please ignore the details.

This required CounterReq to be handled synchronously, within the same time frame.
I’m not sure whether applying this request-response style across the entire project was a good idea.