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