6 Commits

Author	SHA1	Message	Date
G. Allais	3f6b99e979	[ fix #657 ] RigCount for interface parameters (#808)	2020-12-11 11:58:26 +00:00
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	d18aac7afd	Move Data.ST to Control.Monad.ST ... Seems a more appropriate place in the hierarchy (also roughly consistent with where it is in Haskell base)	2020-06-20 12:51:38 +01:00
Edwin Brady	ab03249d49	Add Data.STRef and a generic Ref interface	2020-06-20 00:46:20 +01:00