MonadIO instance for Sem - Polysemy

What is the motivation for the MonadIO instance of Sem r to be

instance (Member (Embed IO) r) => MonadIO (Sem r) where

instead of

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.

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

Would their generalization break anything serious?