Replies: 1 comment
-
| On taking another look at this, I think it's very possible I've simply "switched" the directions of borrow/lend / lift/unlift in my head... I've just tried rewriting it as: [...] UnliftResponse -> localSeqUnlift env $ \unlift -> localSeqLend @'[ScottyIO] env $ \lend -> fmap (. raise) . unlift . lend $ defaultUnliftResponseand this compiles. So it seems I just totally confused myself and in fact was supposed to transform the input parameter of the unlift response function to Just wanted to say thanks for writing this brilliant library! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I just wanted to start off by mentioning I haven't been using
effectfulfor that long so it's possible I'm missing something crucial here. So the TLDR is that I'm trying to essentially wrap the monad transformer typeScottyTfromscottywitheffectful, so that I can have a givenEff esmonad inActionT m acontext and thus run all the stuff I need to do like talking to the DB and such without having to unlift every single thing toIOor sprinkleIOE :> eseverywhere (scottyneedsminActionT m ato have an instance ofMonadUnliftIO). Most of the work is done for this, but I'm just playing around with including what is essentially an effect action likeUnliftResponse :: m (m Response -> IO Response)in my effect, and how exactly to deal with lifting the inner monad during handling.The setup looks like so:
ScottyIOeffect:This effect is essentially just a marker to let me write a newtype monad transformer
ScottyInner(see below) with its ownMonadIOandMonadUnliftIOinstances when theScottyInner-transformed monad is someEff eswhereScotty :> es, ScottyIO :> es(Scottyhere necessary as I pass some options through that - right now this is anUnliftStrategyfor theMonadUnliftIOinstance).Just as a small explanation, I'm creating
MonadIOandMonadUnliftIOinstances since those are constraints are imposed by my usage ofscotty.Scottyeffect:... where
ScottyOptsis just a product type with some field optics defined (fromoptics):Now, the issue I have is in the handler for this
Scottyeffect. Here's what I'm currently working with:defaultUnliftResponsejust presents the unlifting function provided within theMonadUnliftIOinstance forScottyInnerwherem ~ Eff es, Scotty :> es, ScottyIO :> esinScottyInner m(so essentially the(unlift . runInner)expression below):Now, my issue is that I get the following error:
So I'm calling the
borrowfunction handed out bylocalSeqBorrowin order to cleave off theScottyeffect from the outer monad fromdefaultUnliftResponse(i.e.Eff (Scotty : es) (Eff (Scotty : es) Response -> IO Response)toEff es (Eff (Scotty : es) Response -> IO Response)whereScottyIO :> es), and after I'm trying to compose withraisesuch that I can return theEff es Response -> IO Responsefunction required to match the signature ofUnliftResponse :: m (m Response -> IO Response).I'm simply struggling to wrap my head around how this equality constraint
localEs ~ eshas even been introduced. Is it an issue with callingraise? I can't see any other way to return the required function, sinceborrow :: forall a. Eff ('[Scotty] ++ es) a -> Eff es a(wrong way round) and callingrunWithOpts :: ScottyOpts -> Eff (Scotty : es) -> Eff esalso wouldn't work (again, wrong way round).In the end the point is to be able to write something like this to turn a
scottyrouter into a WAI application to then run manually on WARP or something:Sorry that my explanation has been super long and I suppose it's a somewhat contrived example since for all intents and purposes I'll probably only be switching out the relevant
UnliftStrategyfor unlifting theResponseactions, but in a sense this has become a bit of a learning example for how to use the library more generally, so any help decoding this error would be greatly appreciated.Beta Was this translation helpful? Give feedback.
All reactions