UniqFM library

[Duncan Coutts]

On Mon, 2009-09-28 at 14:53 +0100, Simon Peyton-Jones wrote:
> | P.S. Do you have any thoughts on splitting UniqFM out as a library?
> | Or even better, replacing UniqFM with an existing library?
> | I am happy to do any refactoring that may be needed...
> 
> Making UniqFM into a separate package would be a fine thing; one would
> probably include Unique and UniqSupply.  Doing so is the main thing we
> need to support making the dataflow optimisation framework into a
> separate package.  

>From a very brief look, it does not seem that UniqFM is a dependency of
the dataflow framework. It is at least not mentioned in cmm/Dataflow.hs
and is only mentioned in some of the cmm/Cmm* modules which look like
they might use the datflow framework, but not define it.

UniqFM looks like it is just an IntMap but with a class that gives you
the Int key for various different types. A benchmark ought to be able to
confirm if the current UniqFM or IntMap is quicker.

Of course, a class of types that may be used as keys in an IntMap may
well be generally useful. I know I've wanted to be able to use
newtype'ed Ints as keys in an IntMap before without having to deal with
the unwrapping in the main application code. Perhaps such a thing is
appropriate for the containers library.

Avoiding adding extra boot packages that would be exposed to all users
seems like a good thing in general. If they are exposed to all users
it'd be nice if they passed the same quality criteria as other platform
packages. We now have a procedure for adding platform packages. Of
course all that can be bypassed if the boot packages do not need to be
exposed to the end user.

Duncan