Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.
What is the motivation for the MonadIO instance of Sem r to be
instance (Member (Embed IO) r) => MonadIO (Sem r) where
instance (MonadIO m, Member (Embed m) r) => MonadIO (Sem r) where
@Georgi Lyubenov // googleson78 Not sure if there's some original motivation - I guess you can make a PR :big_smile:
Thinking about it, I don't see any situation where the existing code would break - I may be wrong though
Former instance has no ambiguity issues, and embedToMonadIO means we don't lose any flexibility by using that instance.
Yeah, question is if such instance would be more convenient in general - maybe something like Members [Embed IO, Embed (SomethingT IO)] r could require additional annotation, but I think that's a pretty artificial case.
I think it would be nice to remove this "indirection" of having to use embedToIO.
Members [Embed IO, Embed (SomethingT IO)] r
There's the issue of consistency. Interpreters in polysemy use Embed IO, not Embed m, MonadIO m, so if you'd use that embedToMonadIO is necessary anyway
Embed m, MonadIO m
Would their generalization break anything serious?