Drawbacks of System.IO being bound to MonadIO instead of IO?

Learn
#1

What are the drawbacks of System.IO / Base being bound to the MonadIO typeclass instead of straight IO?

Effect systems are becoming quite popular, and MTL has been normative for years. Polymorphic System.IO would make it much more convenient to use Prelude IO functions (i.e, saving you a ton of liftIOs), and the same would apply to corresponding functions in quasi-base like ByteString and Text.

#2

Curiously enough, here’s a thread involving the opposite choice - using IO a directly:

Based on the OP’s comments therein, the major (theoretical) concern with switching System.IO or base to the MonadIO class would be a drop in performance.

1 Like
#3

Is it really “a ton” of liftIOs? From my understanding the usefulness of effect systems is in the ability to decouple function definitions and their implementations, so most (if not all) of the IO should reside in those implementation parts.

1 Like
#4

…and then I forgot the practical concerns:

  • having to update all those type signatures - both in code and learning materials;

  • I/O in Haskell already presents a challenge for educators - adding another layer of abstraction would only make it more so.

1 Like
#5

I think you’re asking “why don’t we use MonadIO in System.IO?”. (At first it sounded like you were asking the opposite.)

If that’s what you want you can have it now in an alternative Prelude/standard library for example rio.

3 Likes