Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Chris Kuklewicz <haskell <at> list.mightyreason.com>
Subject: ANN: TextRegexLazy 0.70 (stable)
Newsgroups: gmane.comp.lang.haskell.libraries
Date: Friday 11th August 2006 17:06:17 UTC (over 11 years ago)
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
 
CD: 4ms