Bulat Ziganshin wrote:
Hello Chris,
Wednesday, August 2, 2006, 3:16:58 PM, you wrote:
Announcing: TextRegexLazy version 0.56
your feature list is really strong! it will be great now to make it a part of GHC standard distribution
afaiu, selection of regex engine implemented via import statements?
Well, yes. The "makeRegex" is provided by each of the 4 backends to create its own Regex type. So there are 4 different data types: Text.Regex.Full.Regex Text.Regex.DFA.Regex Text.Regex.PCRE.Regex Text.Regex.PosixRE.Regex I might be able to make a "framework" polymorphic type: data Regex backend = .... hmmm....
as long-standing goals i can point to support of lazy bytestrings,
Lazy bytestrings are very specialized. You could probable "unpack" them and send them to the Full or DFA backends.
UTF-8,
The Posix backend will never understand unicode of any type. The PCRE backend, if compiled properly, does understand UTF8. You need an encoder/decoder between Unicode [Char] to UTF8 CStringLen or ByteString. The Full and DFA backends understand Char and are therefore already Unicode compliant.
filename wildcards.
What is a FilePath? Ooops...wrong thread!
but that is really more the details than essentials and now testing/bundling with GHC is most important (of course, imho)
More testing is a must. But the 352 ways to operate it make this annoying. More documentation is just grunt work.