Overriding handler / interposeing: how to fordward actions?

[MuhammedZakir]

For this effect:

data E :: Effect where
  Op  :: E m ()
  Op2 :: Eff (E ': es) a -> E m ()

when Op2 is called, I want to handle the E effect inside it using a different handler, something like

runE = interpret $ \_ -> \case
  ...
  Op2 action -> interpose $ \env act -> liftIO (print "augmented) >> send act
  ...

To be precise, in this case, I want to send a signal when any E effect is handled inside action, without affecting existing handlers.

If above is not possible, I am fine with this (if it will work):

runE =  <real handling here>

runIfInsideOp2 = interpose $ \_ act ->
  if insideOp2
  then liftIO (putStrLn "signal") >> send act
  else send act

finalIO = runEff . <other handlers> . runE . runIfInsideOp2

However, for above, I am getting this error:

• Couldn't match type ‘localEs’ with ‘es’
      Expected: e0 (Eff es) a1
        Actual: e0 (Eff localEs) a1
  --snip--
• In the first argument of ‘send’, namely 'x'
  --snip--

---

Edit: Thanks a lot for this library. It is great! :-D

[arybczak]

Thanks a lot for this library. It is great! :-D

Thanks 🙂

I'm not sure what you're trying to do and the code doesn't really tell me this (the snippets are not valid code that can generate relevant compile errors). Can you elaborate and provide better code samples?

[MuhammedZakir]

That's a bummer. I guess what I want is not possible atm. Is it that Haskell doesn't support this, or does it have to do with the library (not implemented, a side-effect of the design, etc.)?

Regardless, thanks for your time! :-)

[arybczak]

This seems to work (it needs #88 to compile):

data E :: Effect where
  GetS   :: E m String
  PutS   :: String -> E m ()
  PrintS :: String -> E m ()
  LocalS :: m a -> E m a
type instance DispatchOf E = Dynamic

runE :: forall a es. (IOE :> es) => [String] -> Eff (E : es) a -> Eff es [String]
runE strings = reinterpret (execState strings) $ \env -> \case
  GetS -> do
    str <- gets head
    modify @[String] tail
    pure str

  PutS str -> modify (str :)

  PrintS str -> liftIO . putStrLn $ "send: " <> str

  LocalS action -> localLiftUnlift env SeqUnlift $ \lift unlift -> do
    unlift $ interpose (augment lift) action

  where
    augmentation :: Eff (State [String] : es) ()
    augmentation = do
      liftIO $ putStrLn "augmented"

    augment
      :: E :> localEs
      => (forall r. Eff (State [String] : es) r -> Eff localEs r)
      -> EffectHandler E localEs
    augment lift env = \case
      GetS          -> lift augmentation >> send GetS
      PutS str      -> lift augmentation >> send (PutS str)
      PrintS str    -> lift augmentation >> send (PrintS str)
      LocalS action -> do
        lift augmentation
        localSeqUnlift env $ \unlift -> do
          send . LocalS $ unlift action

run :: IO [String]
run = runEff . runE (fmap show [1..5::Int]) $ action
  where
    action = do
      s <- send GetS

      send . LocalS $ do
        send . PutS $ s <> s
        s' <- send GetS
        send . PrintS $ "inside: " <> s'

      s' <- send GetS
      send . PrintS $ "outside: " <> s'

Isn't this what you want? The augment function needs to case-split to handle the inner LocalS properly, but that's it.

Note that with this and nested calls to LocalS you will get multiple augmentations, if you just want one level of augmentation:

    augment lift env = \case
      GetS          -> lift augmentation >> send GetS
      PutS str      -> lift augmentation >> send (PutS str)
      PrintS str    -> lift augmentation >> send (PrintS str)
      LocalS action -> do
        lift augmentation
        localSeqUnlift env $ \unlift -> unlift action

this will do the trick.

[MuhammedZakir]

Yeah, that works! ! When I mentioned "what I want is not possible", I was referring to not having to "handle" each operation of the effect manually.

P.S. Is there anything blocking that PR? Also, will you push a new version to hackage after merging, or should I use the repo directly as dep's source?

[arybczak]

Yeah, that works!

Great 👍

When I mentioned "what I want is not possible", I was referring to not having to "handle" each operation of the effect manually.

Yeah, unfortunately you need to handle the operations one by one, because higher order actions need their arguments transformed with the unlifting function and you can't really do that generically.

Is there anything blocking that PR?

No, I just merged it.

Also, will you push a new version to hackage after merging, or should I use the repo directly as dep's source?

I'll release a new version in a few days, so you can use the repo directly until then.

[MuhammedZakir]

Thank you! :-D