Packages in GHC 6.6

Chris Kuklewicz haskell at list.mightyreason.com
Wed Aug 23 07:22:22 EDT 2006


Simon Marlow wrote:
> 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.

Of course it is okay.  All the regex-* packages are in a single darcs repository 
right now.  Do you need a separate repository which only includes the parts that 
GHC will include?  I am still gaining proficiency with darcs, and so I am not 
sure if the canonical repositories should be separate trees or not.

The cabal packages all depend on (fps >= 0.7) to supply Data.ByteString. 
Currently there are:
   regex-base   (everything below depends on this)
   regex-compat (depends on regex-posix and replaces Text.Regex)
   regex-posix  (depends in regex in posix c library, must supply for Windows)
   regex-pcre   (depends on libpcre, which is BSD)
   regex-tre    (depends in libtre, which is LGPL)
   regex-parsec (no c dependency, but needs Parsec)
   regex-dfa    (no c dependency, but needs Parsec) (Note: Engine is LGPL)
   regex-devel  (depends on everything above)

I will email you 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.

I have not added the boilerplate haskell headers to everything.  I will go 
through them and add it, probably tonight, to at least regex-base/posix/compat.

>> 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 ;-).

Okay, I will feel free to remove a few _|_ conditions.


More information about the Libraries mailing list