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. I do want to extract the existing Text.Regex(.Posix) from the base package. 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 ... 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. 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? 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. So we could either: - work on regex-base/regex-posix for inclusion in GHC, or - 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