At 8:44 PM -0700 5/6/02, Mark Kvale wrote:
>
>Hi all,
>
>One of the upcoming decisions that needs to be made is on the design
>of the Parrot regex engine. More specifically, (1) how will compiled
>regexes be represented and (2) how will strings be matched against
>compiled regexes?
As I come in l
On Mon, May 06, 2002 at 08:44:03PM -0700, Mark Kvale wrote:
>
> To compare schemes (A), (B), and (C), I implemented each of them. I
> created a common parser for the three schemes that recognizes the
> basics: ^, $, ., a, \a, [a], [^a], ab, a|b, a*, a+, a? and (a). The
> parsed regex can be conv
On Mon, May 06, 2002 at 09:38:00PM -0700, Brent Dax wrote:
> (FYI, I'm the main author of Parrot's rx package.)
>
> Mark Kvale:
> # computes dynamically several functions, such as length of the
> # regex match string, that are precomputed in the reg code...
> #
> # Note that the overhead/match
In the interests of brevity, I cut huge tracts of quoted text.
On Mon, 6 May 2002, Brent Dax wrote:
> (FYI, I'm the main author of Parrot's rx package.)
>
I'm pleased to meet you.
> Mark Kvale:
> # Warning: this is a long message, a small paper really. The
> # So creating (A) or (B) wil
(FYI, I'm the main author of Parrot's rx package.)
Mark Kvale:
# Warning: this is a long message, a small paper really. The
# synopsis is that I have created a simple regex compiler with
# multiple backends to test proposed regex coding schemes.
# Details and test results are below.
#
# Hi al
