base package -- goals
marlowsd at gmail.com
Wed Feb 27 18:12:47 CET 2013
On 25/02/13 19:25, Johan Tibell wrote:
> 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.
+1 to all that.
I'd like to add one other thing that we've been wanting to clean up: the
unix/Win32 packages should sit low down in the dependency hierarchy, so
that the IO library can depend on them. Right now we have bits and
pieces of unix/Win32 in the base package, some of which have to be
re-exported via internal modules in base to unix/Win32 proper
I seem to recall the situation with signal handlers being a bit of a
mess: the code to handle signals is in base, but the API is in unix.
Glancing at the code in GHC.Conc.Signals it looks like I even had to use
Dynamic to get around the dependency problems (shhh!).
Cleaning up things like this is a win. But I'm with Johan in that
having fine-grained packages imposes a cost on the clients (where the
clients in this case includes everyone), so there should be significant
tangible benefits (e.g. more stability).
More information about the Glasgow-haskell-users