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