Text.Regex.Lazy

Version 0.70 (2006-08-10)

By Chris Kuklewicz (TextRegexLazy (at) personal (dot) mightyreason (dot) com)

• regex-tre added for libtre backend (Text.Regex.TRE), see http://laurikari.net/tre/
• regex-devel added for tests and benchmarks
• Text.Regex.*.Wrap APIs improved: the exported wrap* functions never call fail or error under normal circumstances, and use Either types to report errors. Allocation failures are reported with fail.
• Text.Regex.*.(ByteString|String) all should export compile/execute/regexec functions which report errors using Either.

• I broke this into many packages, regex-base for the interface and regex-pcre, regex-posix, regex-parsec, regex-dfa for the four backends and regex-compat to replace Text.Regex(.New)
• The top level Makefile now can drive setup and installation of all the packages at once.

• JRegex has been assimilated: PCRE and PosixRE are here. The JRegex-style API rocks, see below and Context.hs and Example.hs
• Haddock seems to run via ./setup haddock, but the documentation is very thin
• ./setup test runs TestTestRegexLazy binary if uncommented in cabal file
• default is now to compile with -Wall -Werror -O2
• You may need to point the cabal file's "Extra-Lib-Dirs" to point to pcre.
• You may or may not need a "-lpcre" option to ghc when building projects that depend on Text.Regex.Lazy now.

• Cabal
• Compile with -Wall -Werror
• Change DFAEngineFPS from Data.FastPackedString to Data.ByteString

• Posix, the standard c regex library
• PCRE, the Perl Compatible Regular Expressions c library
• Full, the lazy Parsec based library (see old api below)
• DFA, the fast lazy matching library (see old api below)

For simplest use of the new API: import Text.Regex.Lazy and one of

import Text.Regex.PCRE((=~),(=~~))
import Text.Regex.Parsec((=~),(=~~))
import Text.Regex.DFA((=~),(=~~))
import Text.Regex.PosixRE((=~),(=~~))
import Text.Regex.TRE((=~),(=~~))

You can redefine (=~) and (=~~) to use different options by using makeRegexOpts:

(=~) :: (RegexMaker Regex CompOption ExecOption source,RegexContext Regex source1 target) => source1 -> source -> target
(=~) x r = let q :: Regex
               q = makeRegexOpts (some compoption) (some execoption) r
           in match q x

(=~~) ::(RegexMaker Regex CompOption ExecOption source,RegexContext Regex source1 target,Monad m) => source1 -> source -> m target
(=~~) x r = let q :: Regex
                q = makeRegexOpts (some compoption) (some execoption) r
            in matchM q x

The low level APIs are in the Text.Regex.*.Wrap modules. For the c-library backends these expose most of the c-api in wrap* functions that make the type more Haskell-like: CString and CStingLen and newtypes to specify compile and execute options. The actual foreign calls are not exported; it does not export the raw c api.

Also, Text.Regex.PCRE.Wrap will let you query if it was compiled with UTF8 suppor: configUTF8 :: Bool. But I do not provide a way to marshall to or from UTF8. (If you have a UTF8 ByteString then you would probably be able to make it work, assuming the indices PCRE uses are in bytes, otherwise look at the wrap* functions which are a thin layer over the pcreapi).

The old Text.Regex API is can be replaced. If you need to be drop in compatible with Text.Regex then you can import Text.Regex.New and report any infidelities as bugs. Some advantages of Text.Regex.Parsec over Text.Regex:

• It does not marshal to and from c-code arrays, so it is much faster on large input strings.
• It consumes the input String in a mostly lazy manner. This makes streaming from input to output possible.
• It performs sanity checks so that subRegex and splitRegex don't loop or go crazy if the pattern matches an empty string -- it will just return the input.
• If the String regex does not parse then you get a nicer error message.

Internally it uses Parsec to turn the string regex into a Pattern data type, simplify the Pattern, then transform the Pattern into a Parsec parser that accepts matching strings and stores the sub-strings of parenthesized groups.

All of this was motivated by the inability to use Text.Regex to complete the regex-dna benchmark on The Computer Language Shootout. The current entry there, by Don Stewart and Alson Kemp and Chris Kuklewicz, does not use this Parsec solution, but rather a custom DFA lexer from the CTK library.