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