What: "TextRegexLazy" version 0.70 Where: darcs get --partial http://evenmere.org/~chrisk/trl/stable/ (and darcs get --partial http://evenmere.org/~chrisk/trl/head/ ) The conversion to separate regex-* packages seems stable now. More changes will be done as part of interfacing with GHC. What should I do to advance the plan of changing GHC's regex support? Note that the new Posix library backend is much higher performance than the old one when searching for all the (non-overlapping) matches. The regex-compat package provides Text.Regex.New that uses this better wrapping. The low level API from the Wrap modules always handles errors with Either types. The (Byte)String modules provide a medium level API that handles errors with Either types (compile/execute/regexec). By comparison, the "match" or "=~" high level API still calls error or fail. The build environment will have to be slightly edited when installing. Details are in the README file (and you can and should email me questions). I would appreciate someone with ghc on windows to build as many of the packages as possible and tell me how to do it or how to fix it. GHC includes a copy of the Posix regex library to compile on windows, but regex-posix does not do this (yet). regex-parsec may undergo some small changes to give it a more posix-compatible mode. Right now QuickCheck has found some sub-expression captures that are different for pcre and posix, and parsec agrees with pcre in its left-most strategy but does not always agree with posix in its longest strategy. -- Chris