base package -- goals

[Simon Marlow]

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