I think it would be vv helpful to have all these goals articulated on the wiki
page.
http://hackage.haskell.org/trac/ghc/wiki/SplitBase
For the "avoiding version bump" goal, I still don't see why having a simple
"shim" package on top whose API is stable, and whose version number changes
seldom, would not do the job.
Simon
From: Johan Tibell [mailto:[email protected]]
Sent: 25 February 2013 19:25
To: Joachim Breitner
Cc: [email protected]; Simon Peyton-Jones
Subject: Re: base package -- goals
Hi all,
Let me add the goals I had in mind last time I considered trying to split base.
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.
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.
-- Johan
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
