6.6 plans and status

[Simon Marlow]

Chris Kuklewicz wrote:

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

Is it possible to provide both?  Perhaps deprecating the current API?

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

I'm not keen on adding a PCRE dependency.  We already include an implementation 
of POSIX regexes in GHC itself (libraries/base/cbits/regex) which tends to get 
used on Windows where there isn't an implementation of POSIX regexes

> The problem is that String is very 
> inefficient with Posix or PCRE and ByteString is slightly inefficient 
> with Haskell/Parsec.

Do you have any measurements (rough measurements would be fine)?  When you say 
"very inefficient", by what factor is the Parsec implementation faster than 
using the Posix one for Strings?

If we were to use the Parsec implementation, that pulls in another dependency. 
Not out of the question, but to be avoided if possible.

>> So we could either:
>>
>>   - work on regex-base/regex-posix for inclusion in GHC, or
> 
> I could prepare this for you.

Great, thanks!

> 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)?

We want to replace Text.Regex.  So ideally you want to do this in a GHC tree, so 
you can remove the old Text.Regex and replace with yours.  If this is too 
difficult, then you could develop it separately (as Text.Regex.New, or 
something), and I'll make the relevant changes when I import it.

Cheers,
	Simon