Packages in GHC 6.6

[Simon Marlow]

Chris Kuklewicz wrote:
> 
> Simon Marlow wrote:
>  > Here is what I propose to do regarding the libraries we ship with GHC
>  > 6.6.  Comments are appreciated, since we need to finalise this story
>  > before the release candidate at the end of this week.
>  >
> 
> I have a small comment...
> 
>  > So here's what I propose:
>  >
>  >  - A "GHC source tree" will contain a core set of packages.  This is
>  >    what you will get if you download ghc-6.6-src.tar.bz2, or do
>  >    "sh darcs-all get" in a darcs repo.  The core packages are:
>  >
>  >       base, haskell98, template-haskell, readline, stm,       Cabal, 
> unix, Win32
>  >       plus hopefully regex-base and regex-posix if I integrate them this
>  >    week.  These are the packages required to bootstrap GHC, or those
>  >    with deep GHC dependencies (template-haskell & stm).
>  >
> 
> You will also want regex-compat if you want to keep the old Text.Regex 
> module API.  (Renaming Text.Regex.New to Text.Regex)
> 
> I have just gone over the stable repository [1] for 
> regex-base,posix,compat and tweaked the cabal files to better match the 
> packages they actually depend upon.  The latest version of these is now 
> 0.71

Is it ok if I take this code and turn it into separate repositories on 
darcs.haskell.org?  Would you like to adopt the new repositories as the 
canonical location?  I can set you up with a darcs.haskell.org account, just 
send me an SSH public key.

How is the Haddock documentation?  I noticed some of the modules didn't have 
Haddock headers on, this is standard practice in the libraries.

> But I suspect you don't use cabal to build these for GHC.
> 
> The posix c library is slow, but at least it is what people have been 
> using. Note that Text.Regex.New from regex-compat is so close to 
> Text.Regex that it shares the same "bugs", such as splitting or 
> substituting with a pattern that matches an empty string and going into 
> an infinite loop.
> 
> Should I sacrifice a little backwards compatibility and catch these "bugs"?

I'd say that would be fine, replacing _|_ in a library API with something useful 
can't be a bad thing (unless you do it non-deterministically ;-).

Cheers,
	Simon