6.6 plans and status

[Chris Kuklewicz]

Simon Marlow wrote:
> Chris Kuklewicz wrote:
>> Would a new and expanded Regex package (Test.Regex.Lazy) be something 
>> that could be included in the 6.6.0 libraries?  What is the best 
>> practice for getting it included?
> 
> Since we're aiming to include fewer libraries under the GHC umbrella, 
> not more, this wouldn't be the right approach.  Also, I'm sure you want 
> the ability to release Text.Regex.Lazy independently of GHC, so tying it 
> to the GHC release cycle would be unduly restrictive.

Possibly true.

> I do want to extract the existing Text.Regex(.Posix) from the base package.

"base" seems the wrong place.

> So we should think about what structure we want for regex packages.  
> Here's one possible plan:
> 
>   regex-base    shared regex code
>   regex-posix    the POSIX backend
>   regex-pcre    the PCRE backend
>   ...

That could work well.  It would not involved too much pulling apart.

Once small quirk is there is the old Text.Regex API and a new JRegex-style API.

> We should have one "default" implementation that provides regexes over 
> Strings and ByteStrings.  I don't really mind which backend that is, as 
> long as it is fast and BSD-licensed.

A "default" backend has to be dependably present. That means either keeping the 
current Posix backend, adding a dependency on PCRE, or using the Haskell/Parsec 
backend.  The problem is that String is very inefficient with Posix or PCRE and 
ByteString is slightly inefficient with Haskell/Parsec.

> We could then include a subset of these packages (optionally) in GHC 
> binary distributions, so that users would have access to basic regex 
> functionality out of the box.  How does that sound?

That seems like the best plan.

> Ah, I just realised that GHC itself uses regexes in a couple of places, 
> so I do need to include basic (String) regex functionality in the 
> libraries. 

I assume that is the Posix Text.Regex syntax.  So you need support for this 
syntax in GHC.

> So we could either:
> 
>   - work on regex-base/regex-posix for inclusion in GHC, or

I could prepare this for you.

> 
>   - I could just extract Text.Regex(.Posix) from the base package into
>     a separate package.

> 
> obviously the first option is better, but time is short.  Let me know 
> what you think.
> 
> Cheers,
>     Simon

I'll assemble a version organized like that this week.  Important question:
Should I be planning to install alongside the current Text.Regex(.Posix) or 
planning on replacing them? (With an identical API)?

-- 
Chris