8 Commits

Author	SHA1	Message	Date
Stefan Höck	8d4321eb9a	Add Data.Bits to base (#1033)	2021-03-04 20:59:56 +00:00
Denis Buzdalov	b355b12cdb	Some cleanup was done. Changed code is mosly equivalent to the former. ... A lot of useless matches of implicit arguments were removed.	2021-02-16 19:05:33 +00:00
russoul	3a9b1ac656	Add supporting code	2020-08-25 14:30:57 +03:00
russoul	594105d5ac	Eliminate schemeCall from the library	2020-08-24 19:38:29 +03:00
Kamil Shakirov	8544e80076	Use the same naming convention for foreign primitives	2020-08-19 14:05:28 +01: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	1b15463746	Update libraries and docs with HasIO/MonadIO	2020-06-21 15:25:40 +01:00
Edwin Brady	dec7dff622	Add libraries	2020-05-18 14:00:08 +01:00