Skip to content

Do we need mergeGPromptly also? #509

@bglgwyng

Description

@bglgwyng

Just as we have both switchHold and switchHoldPromptly, I think we need mergeGPromptly over mergeG.

processRequestIntMap' ::
  forall t m req resp.
  (Reflex t, MonadFix m, MonadHold t m, Adjustable t m) =>
  Event t (IntMap (m (Event t (Some resp)))) ->
  Event t (RequesterData req) ->
  m (Event t (IntMap (Some req)), Event t (RequesterData resp))
processRequestIntMap' eOutResp' eReq = mdo
  (eInReq, eOutResp) <-
    matchResponseMapWithRequests
      encdecSome
      eReq
      eInResp

  let eInResp = pushAlways pure $ mergeIntMapIncremental iAdjusted
  iAdjusted <- holdIncremental initial ePatch
  (initial, ePatch) <-
    traverseIntMapWithKeyWithAdjust
      (\k v -> v)
      mempty
      ( ( ffor eInResp (fmap (const Nothing))
            <> (fmap Just <$> eOutResp')
        )
          `ffor` PatchIntMap
      )

  pure (eInReq, eOutResp)

I'm writing such a function and the usage of mergeIntMapIncremental creates a problem that the prompt response is not handled properly. I add delay 0 as a workaround to fix this issue for now. If we have such function mergeIntMapIncrementalPromptly, then it will work without the workaround.

It's related to #508 and #505

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions