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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
