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