It would be really great if libraries just used MonadEffect and MonadAff so that their functions seamlessly fit into my code.
Thanks everyone lets get started on the transition.
1 Like
There is a performance overhead to using constraints over the unlifted type, so generally I like to include the operations lifted and unlifted. Effect.Console and Effect.Console.Class being a good example of that.
2 Likes
No thank you - I really don’t think writing the occasional liftAff or liftEffect is worth the cost of worse type inference and type error messages, and making type signatures more complicated. Additionally, you often can’t use MonadAff or MonadEffect when you’re taking an Aff or Effect action as an argument.
3 Likes
All these reasons seem like orthogonal reasons not to because the compiler isn’t good enough yet.
1 Like
I am using lift, liftAff, liftEffect on a large number of lines if I’m working in some other monad. Again it seems like the compiler not supporting these well is to blame here.
1 Like
Not really - the compiler can always improve on error messages, but there’s a limit to what you can do there. MonadEffect is just more complicated than plain Effect, and there’s no way around that.
1 Like
Yeah, good point. ^ This is referring to the fact plain Effect can be specially optimized in a way that will never be workable for MonadEffect as it doesn’t apply to monads in general - it basically turns a sequence of Effect binds into plain JS statements.
1 Like
Personally I wasn’t really thinking about generated code, I was more referring to type inference, type checking, and generation of error messages. Having fewer type classes and type variables floating around will usually simplify things. Even with really good error reporting, putting an Aff somewhere an Effect should go (or vice versa) is always going to generate an error which is easier to understand compared to if everything has been lifted.
2 Likes
Have either of you seen any “papers” that address how to merge these disparate monads more easily?
1 Like