base package (Was: GHC 7.8 release?)

Joachim Breitner mail at
Fri Feb 15 09:36:36 CET 2013


Am Donnerstag, den 14.02.2013, 21:41 -0500 schrieb brandon s allbery
> On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote:
> > On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner
> > <mail at> wrote:
> > I don't think having FFI far down the stack is a problem. There are
> > lots of pure data types we'd like in the "pure data" layer (e.g.
> > bytestring) that uses FFI. As long as the I/O layer itself
> > (System.IO, the I/O manager, etc) doesn't get pulled in there's no
> > real problem in depending on the FFI. 

I think it would be nice, also to other Haskell implementations that
might have not have FFI, to separate the really basic stuff from
pure-but-impurely-implemented stuff. At least as long as it does not
caues trouble.

GHC.Fingerprint does not need to be crippled when it is going to use a
pure hashing; I quickly added some simple fingerpriting found via
Wikipedia that was easier than MD5.
The choice is of course not final, maybe something with more bits is

> Doesn't the FFI pull in some part of the I/O layer, though?  In
> particular threaded programs are going to end up using forkOS?

Another good reason to try to have a pure ground library.

Based on base-pure, the next step would be to check if FFI can be
provided without IO (but I doubt that is difficult), so there would be
an base-io package on top of base-pure, and then bytestring can depend
on that base-io and base-pure, while users of bytestring of course don’t
have to depend on base-io (as long as they are not using the IO-related
functions of bytestring).

 * Does anyone have a tool to compare package APIs? It would be
interesting to diff base’s API with the combined APIs of the package we
are creating right now.
 * Currently, base-pure exports lots of modules that should not be part
of its “pure” API (all the GHC.* packages). But I assume they need to be
exported for the benefit of packages like base-io built on top. Should
we provide another package that re-exports those that are for public
consumption and is likely to have a more stable API? Again I feel the
need for packages re-exporting modules without incurring a conflict.
 * What to do with Prelude. Should it be in base-io (which is
potentially the lowest package containing everything needed) or rather
in a package of its own? Or should it live in a package of its own? Or
can we use the haskell2010 package for that somehow?
 * Should base-io provide just the IO monad and all, say, file-related
stuff in a separate package or is this going too far?


Joachim "nomeata" Breitner
Debian Developer
  nomeata at | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Glasgow-haskell-users mailing list