Does anyone have an example of doing this? In particular looking to wrap MonadHttp from the req library, and see what it takes to handle its http errors the polysemy way.
explicit dictionary passing? would be really nice to have some more infrastructure for that. no idea if ConstraintAbsorber is suitable for arbitrary classes, it looked to be a bit above my pay grade
instanceMembers[EmbedIO,<whatever-errors-I-want-for-http-errors>]r=>MonadHttp(Semr)where-- something like this, don't exactly remember the IO part-- but you need some form of it, because of the MonadIO constraint on MonadHttp
It's not very pretty, but I don't care too much, since it's "application code"
instanceMembers[EmbedIO,<whatever-errors-I-want-for-http-errors>]r=>MonadHttp(Semr)where-- something like this, don't exactly remember the IO part-- but you need some form of it, because of the MonadIO constraint on MonadHttp
It's not very pretty, but I don't care too much, since it's "application code"
what do you mean? you're having doubts whether this thing works "correctly"?
Primarily whether it is practical or possible for a wider selection of transformers to provide an instance for Sem r. I guess stuff like MonadSnap that depend on MonadBaseControl should be problematic…
Also whether it's ergonomic to integrate this into a polysemy program. Do you have some example code?
Does anyone have an example of doing this? In particular looking to wrap
MonadHttp
from thereq
library, and see what it takes to handle its http errors the polysemy way.cf. https://hackage.haskell.org/package/req-3.2.0/docs/Network-HTTP-Req.html#v:handleHttpException
explicit dictionary passing? would be really nice to have some more infrastructure for that. no idea if ConstraintAbsorber is suitable for arbitrary classes, it looked to be a bit above my pay grade
Going with plain old mtl for now, https://www.srid.ca/088b7edd.html
I made an orphan to deal with this exact problem:
It's not very pretty, but I don't care too much, since it's "application code"
Yeah, you can probably use
reflection
to do this, but it would also be more complicated, so I guess I avoided itOr, because
req
interface is pretty small, you could just defineHttp
effect that interprets intoEmbed Req
, which in turn can be run in e.g.Embed IO
Georgi Lyubenov // googleson78 said:
does that work in general??
what do you mean? you're having doubts whether this thing works "correctly"?
Georgi Lyubenov // googleson78 said:
Primarily whether it is practical or possible for a wider selection of transformers to provide an instance for
Sem r
. I guess stuff likeMonadSnap
that depend onMonadBaseControl
should be problematic…Also whether it's ergonomic to integrate this into a polysemy program. Do you have some example code?
Classes with fundeps like
MonadReader
won't really work withSem
, which has to be polymorphic in effects stack to be usefulTheMatten said:
This looks like an approach that I could deal with when coming back to the code after a year without worrying about not being able to understand it.
IIUC,
req
is the only method I use on MonadHttp; so thisHttp
effect would have one constructor calledReq
? Okay, that's worth playing with.You should just need to pass all the arguments to original
req
Yea. I also have a
GitHub
effect. So mygithubToIO
function can now take theHttp
effect as its member.Oh, and I can perhaps move the API request logging effect to Http itself.
I wonder whether this wouldn't be possible to automate - some TH for wrapping incompatible interfaces into effect with interpreter over
Embed
ded monadyes please!
Haha, I guess I will open both this and https://funprog.zulipchat.com/#narrow/stream/216942-Polysemy/topic/Plugin.20package/near/200407539 as issues so that we don't forget about them :slight_smile:
great!
@Torsten Schmits my "example" code is not very interesting:
and later in my chain of interpreters I have something that is basically the same as runInputSem, in which I do
req
cool thanks!