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 (System.Posix.Internals). 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). Cheers, Simon