MonadIO instance for Sem - Polysemy

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

Georgi Lyubenov // googleson78

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

Love Waern (King of the Homeless)

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.

Love Waern (King of the Homeless)

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?