Re: Topaz and Regular Expressions

Ed Peschko writes:
> embed perl in C++ but it comes at the expense of embedding an interpreter.

I wish there were a direct interface into regex matching (and other ops
for that matter), but I don't see a problem with embedding itself. I
think it's an incredibly difficult challenge to optimize ops without
assuming that a perl interpreter is available. For example, would you
want the regex engine to abstract the concept of evaluating a
replacement string? That might hurt performance/maintanability quite a
bit. Is it worth it?

> Wheras some of us would like to say:
...
> 	while (a.regmatch("H(.*?)(?=H|$)", "sg"))

This interface looks pretty, but it is a total pain to optimize. It
is possible to special case for (const char *) and lookup pre-built
regexps from a cache -- but that leads to surprises when a programmer
changes from a constant to a variable and suddenly the performance
drops by an order.

I'd much rather encourage user-visible regexp objects. IMHO C++ can be
used to hide a great deal of complexity, but when things that look fast
run extremely slowly, the hiding gets in the way. (This is one of the
reasons Linux developers oppose C++ -- it's hard to "get a feel" for
the way code will run by just looking at it.)

Just my $.02 of course. (libperl++ allows (char *) in place of
regexp objects BTW... ;)

> without paying the interpreter overhead. Will this be available 
> 'out of the box' or will a API layer be needed?

I hope that we will be able to run ops directly without bouncing
through the trampoline code. Is that what you mean? I rather think
that an API layer is a very good idea -- I just don't want the API
to be the current perl_call_sv() interface...

- Ken

-- 
Ken Fox, [email protected], (313)59-44794
------------------------------------------------------------------------
Ford Motor Company, Powertrain           | "Is this some sort of trick
Analytical Powertrain Methods Department |  question or what?" -- Calvin
C3P Implementation Section               |