Re: How to move code from GHC to libraries?

2009-09-17 Thread 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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: How to move code from GHC to libraries?

2009-09-14 Thread Simon Marlow

On 12/09/2009 00:02, Norman Ramsey wrote:

Incedentally, the reason I'd like us to make a decision on this now is
because I'm about to add two new boot libraries...

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?


Is there an established procedure for moving a part of GHC into a
library without breaking everybody's build?  If so, where will I find
it on the developers' wiki?  If not, who can advise me so I can create
a page on the developers' wiki? :-)


The architecture of our library setup is here:

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Libraries

Basically you'd be adding a new zero-boot package (that terminology 
isn't used in the build system, where they're called boot packages). 
The best way to find out how to add another one is to grep for an 
existing zero-boot package (e.g. Cabal) in the top-level ghc.mk to see 
the various things you need to add.


The new package would need to have a repository created on 
darcs.haskell.org, and you'd need to add it to $(TOP)/packages too. 
When the changes are pushed, everyone has to ./darcs-all get to get 
the new repository.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users