Constraint on the effects that are out of the monadic flow.

[wclr]

I would like to model a sample app here, one of the functions of it is to be able handle the request and return the response. In this model, it uses the effectful method onRequest to which we pass the handler (response returned will be converted to IO by interpreter and run on each request).

The problem I see here is that the app function in this case doesn't require LogEff effect constraint, which is used in the handler but is not used in the application monadic flow directly, it is only passed to handler here.

In my view, the app's signature doesn't reflect what the app is doing as a whole in this case. It reflects what the monadic flow is doing, not the app. What would you say about such an issue? Maybe it is possible somehow to achieve what I would like to see in this case?

module EffectfulApp where

import Effectful (Eff, Effect, type (:>))
import Effectful.TH (makeEffect)


data LogEff :: Effect where
  LogLine :: String -> LogEff m ()
makeEffect ''LogEff


data Request = Request {reqUrl :: String}
data Response = Response {resText :: String}


type RequestHandler es =
  ( (LogEff :> es) => Request -> Eff es Response
  )


data ReqEff :: Effect where
  OnRequest :: (forall es. RequestHandler es) -> ReqEff m ()
makeEffect ''ReqEff


app ::
  ( ReqEff :> es
  -- LogEff : es -- is not required, and gives the waning
  ) =>
  Eff es ()
app = do
  onRequest \(Request {reqUrl}) -> do
    logLine $ "Got request from " <> reqUrl
    pure $ Response {resText = "Hello!"}

[wclr]

Well, I thought about it, maybe I'm not correct her, LogEff is present inside the ReqEff, so probably it is quite ok then.

[wclr]

Then I will ask here another question, related at least to this sample app.

Here is the interpretation and run module"

module EffectfulAppEntry where

import EffectfulApp (LogEff (..), ReqEff (..), Request (..), app)

--
import Data.Function ((&))
import Effectful (
  Eff,
  IOE,
  MonadIO (..),
  runEff,
  type (:>),
 )
import Effectful.Dispatch.Dynamic (interpret)


runLog ::
  (IOE :> es) =>
  Eff (LogEff : es) a ->
  Eff es a
runLog = interpret \_ -> \case
  LogLine msg -> liftIO $ putStrLn msg


runReq ::
  (IOE :> es) =>
  Eff (ReqEff : es) a ->
  Eff es a
runReq = interpret $ const \case
  OnRequest toResponse ->
    liftIO $ do
      _ <-
        runEff
          ( toResponse Request {reqUrl = "/some"}
              & runLog
          )
      pure ()


main :: IO ()
main = do
  runEff $
    app
      & runReq
      -- we actually don't need logEff here but is is still can be applied
      & runLog

Why is it still possible to apply logEff interpretator to the program even if doesn't need it, and it can be just removed?

[eddiemundo]

The es in Eff es a is polymorphic and so the runXs determine what the concrete effect list is. If you have:

app :: (Req :> es) => Eff es a
app = reqItUp

blah =
  app
    & runReq
    & runLogger

then the type of blah is something like Eff [Req, Logger] a and [Req, Logger] satisfies the constraint Logger :> es.

Doing the extra logEff shouldn't do anything because there are no log operations to interpret.

The interpreters determining the concrete stack is very similar to how mtl-style works.

[wclr]

I understand that it does nothing, but it seems to be misleading that such thing is allowed. In mtl, as you mentioned it, we can not hae yet another runSmthT on stack if it is not appropriate/needed, right?

[ocharles]

If you want your application to have a closed set of effects, then you need to specify that. In

app :: (Req :> es) => Eff es a

You are saying app works for any es, provided Req is somewhere in es.

You could alternatively write

app :: Eff '[Req] a

And now app can only be used with runReq.

That said, this isn't idiomatic. runReq $ runLogger app isn't really a problem to worry about, it's just a bit wasteful

[wclr]

Ok, I see it for the app, b I have a currenlty runReq signature as (IOE :> es) => Eff (ReqEff : es) a -> Eff es a and it doesn't work with closed app,

I tried to replace it with Eff '[ReqEff] a -> Eff '[IOE] a but get the error:

Couldn't match type: '[]
                 with: '[IOE]
  Expected: Eff '[ReqEff] a -> Eff '[IOE] a
    Actual: Eff '[ReqEff] a -> Eff '[] a

And can not get how to put the interperter correctly.

For my case the dummy interperter looks like:

runReq = interpret $ const \case
  OnRequest toResponse ->
    liftIO $ do
      _ <-
        runEff
          ( toResponse Request {reqUrl = "/some"}
              & runLog
          )
      pure ()

[ocharles]

I think we'd need to see full code that we can compile to help here, but I don't think you're going down a very productive path. This is not how effectful is designed to be used - keeping es polymorphic and adding constraints is the idiomatic approach and I think it would be best to try and help building understanding there.

[arybczak]

Indeed, what @ocharles said is accurate.

Using monomorphic effect stacks isn't even supported with higher order effects (see here, specifically the last example), so you shouldn't really do things this way.

Btw, I'll convert this thread to a discussion, since it's not an issue.

[wclr]

@ocharles

I think we'd need to see full code that we can compile.

Well, there is a full code of modules that compiles in the first and the third post: modules EffectfulApp (logic) and EffectfulAppEntry (interpretation and run), besides the extensions used.

@arybczak

Using monomorphic effect stacks isn't even supported with higher order effects (see here, specifically the last example), so you shouldn't really do things this way.

Could you elaborate more on what "monomorphic effect stacks" is and what is wrong with my sample's code/approach?

[arybczak]

Your original code is fine.

Monomorphic stack is just the first parameter of Eff that's, well, monomorphic, e.g. Eff '[IOE] a. Eff es a has a polymorphic stack that can be then constrained with :>, i.e. IOE :> es => Eff es a.

You can read more about this here.

[wclr]

This is not how effectful is designed to be used - keeping es polymorphic and adding constraints is the idiomatic approach and I think it would be best to try and help building understanding there.

So it is ok that, to attach interpreters that are not needed (won't be used) by the program at the moment? Is there a rationale behind this?

[ocharles]

Can you try and explain what the problem you see is? There is an almost insignificant performance hit and that's it

[ocharles]

Well the problem is you are calling runLog right at the end, but app's type is Eff '[ReqEff], so runLog isn't compatible. But that's exactly what you want?

[wclr]

How my interpreters should be modified to make it work with closed effect types.

[ocharles]

@wclr I think the best I can offer is https://play-haskell.tomsmeding.com/saved/gQsOCcNP. The call to inject re-generalizes app to allow IOE

[wclr]

@ocharles Right, and then we go back to where we were in the beginning, now we can add redundant runLog again -)

[ocharles]

Yes. If you don't what that then you would need to annotate the type of inject - something like inject @'[ReqEff] @'[ReqEff, IOE]