Commit Graph

4 Commits

Author SHA1 Message Date
Edwin Brady
dbdf7dab3d Back to HasIO, remove MonadIO
Following a fairly detailed discussion on slack, the feeling is
generally that it's better to have a single interface. While precision
is nice, it doesn't appear to buy us anything here. If that turns out to
be wrong, or limiting somehow, we can revisit it later. Also:

- it's easier for backend authors if the type of IO operations is
  slightly less restrictive. For example, if it's in HasIO, that limits
  alternative implementations, which might be awkward for some
  alternative back ends.
- it's one less extra detail to learn. This is minor, but there needs to
  be a clear advantage if there's more detail to learn.
- It is difficult to think of an underlying type that can't have a Monad
  instance (I have personally never encountered one - if they turns out
  to exist, again, we can revisit!)
2020-06-21 19:21:22 +01:00
Edwin Brady
28855088c2 Split HasIO into HasIO and MonadIO
For things which don't require (>>=), HasIO is fine, otherwise MonadIO
gives access to the monad interface.
2020-06-21 14:46:14 +01:00
Edwin Brady
d12487f529 HasIO interface for IO actions
Also updates the Prelude and some base libraries to use HasIO rather
than using IO directly.
2020-06-21 01:18:43 +01:00
Edwin Brady
dec7dff622 Add libraries 2020-05-18 14:00:08 +01:00