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