How to move code from GHC to libraries?

[Simon Marlow]

On 17/09/2009 04:43, Norman Ramsey wrote:
>   >  >  While we're on this topic, I've had several requests to pull HOOPL
>   >  >  (the new dataflow optimization code) out as a library so that we can
>   >  >  make it into a Hackage package.   I'd like to do this, but the
>   >  >  situation is complicated because HOOPL depends on UniqFM, which is
>   >  >  GHC-specific.  I thought that there was a similar implementation out
>   >  >  in the wild (based on Okasaki-Gill rather than Adams), but I can't
>   >  >  find it on hackage.
>   >
>   >  Isn't Data.IntMap ~= UniqFM?
>
> Yes, thanks --- I couldn't remember the module name, and search did
> not help.
>
>   >  >  Is there an established procedure for moving a part of GHC into a
>   >  >  library without breaking everybody's build? ...
>   >
>   >  The architecture of our library setup is here:
>   >
>   >  http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries
>
>   >  You'd be adding a new zero-boot package...
>
> OK, I would like to propose that I put Data.IntMap into a new
> zero-boot package, and that I replace the existing UniqFM with a
> compatibility layer over Data.IntMap, with the eventual goal of
> expunging UniqFM from the GHC sources.
>
> Any comments or objections?

You can assume that the bootstrapping compiler already has Data.IntMap, 
no need to put it in a 0-boot package.

So in principle using Data.IntMap is a good thing, I wholeheartedly 
support using the standard libraries instead of in-house duplicates 
where possible.  The only potential problem is performance: we rely 
heavily on UniqFM in GHC, so we'd have to make sure that any replacement 
is at least as fast.  The only time to measure it is when making the 
changeover, when you can measure the change in isolation.

Cheers,
	Simon