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
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 all,
One of the upcoming decisions that needs to be made is on the design
of th
