earthquake changes of std.regexp to come

Daniel de Kok me at danieldk.org
Tue Feb 17 12:30:10 PST 2009


On Tue, Feb 17, 2009 at 8:57 PM, Jarrett Billingsley
<jarrett.billingsley at gmail.com> wrote:
> The problem with this method is that while it's certainly faster to
> match, it's MUCH slower to compile.  There are no pathological
> matches; only pathological compiles ;)  I'm talking 60-70 seconds to
> compile a more complex regex. This might be an acceptable tradeoff
> for when you need to compile a regex in a long-running app like a
> server, but it's completely unacceptable for most small, Perl-like
> text munging programs.

Hmmm, define "complex", I suppose it's ok for the general
line-splitting/matching stuff? I got into trouble (time-wise) when we
compiled a part of speech tagger into a transducer. In those cases we
generally pre-compile stuff, and output it as a large struct in the
target language. Of course, it would be fun if we can do it at
compile-time ;).

Besides that, if we'd have a good general recognizer/transducer
implementation it could also be used for compact dictionary storage,
perfect hashing automata, etc.

Take care,
Daniel



More information about the Digitalmars-d mailing list