base package -- goals

Joachim Breitner mail at
Tue Feb 26 09:54:25 CET 2013


Am Montag, den 25.02.2013, 11:25 -0800 schrieb Johan Tibell:
>  1. I'd like to have text Handles use the Text type and binary Handles
> use the ByteString type. Right now we have this somewhat awkward setup
> where the I/O APIs are spread out and bundled with pure types.
> Splitting base would let us fix this and write a better I/O layer.
>  2. The I/O manager currently has a copy of IntMap inside its
> implementation because base cannot use containers. Splitting base
> would let us get rid of this code duplication. 

added to

It would be interesting to see if Text and Bytestring (without the file
IO parts) can be compiled using the base-foreign package extracted here
Looking at the imports, it seems possible. Then a base-io-system package
can indeed depend on text and bytestring, and provide the appropriately
typed file IO functions there.

The containers package looks like a good example for a package that sits
on base-pure: No IO, no FFI. So with the split suggested in my branch,
having the ghc-io-system depend on containers seems possible.

> I'm less interested in having super fine-grained dependencies in my
> libraries. More packages usually means more busy-work managing
> dependencies. Taken to its extreme you could imagine having
> base-maybe, base-bool, and whatnot. I don't think this is an
> improvement. Splitting base into perhaps 3-5 packages (e.g. GHC.*, IO,
> pure types) should let us get a bunch of benefits without too many
> downsides.

This is basically the goal added by SPJ: Split base into as FEW packages
as possible, consistent with meeting the other goals.


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