pcre, bifs, drivers and ports
Fri Aug 4 12:06:14 CEST 2006
The best way to go continue is to decide what we would like a regexp
package to be able to do. I used the regexps and interfaces (sub, gsub
etc) to them from standard AWK which were well defined, stable and
allowed you to do most things. Perhaps the POSIX definition is the way
to go. If we could then agree (difficult :-)) on a common interface we
could have different packages which work in the same way but targeted
att different types of uses. This was the idea behind sets/ordsets and
Most features (for example backreferences) are pretty easy to implement
when interpreting the regexp or using an NFA but difficult compiled/with
a DFA. Actually adding backreferences is to regexp is probably easier
then fixing the bug Fredrik Thulin mentioned. And much more fun. :-)
Ernie Makris wrote:
> Hi Robert,
> Robert Virding wrote:
>>While the handling of "f**" in regexp is definitely a bug, which I
>>suppose I should fix, it is definitely a legal regular expression. So
>>that pcre will not even allow the regular expression is also a bug,
>>the question is if it is the parsing of the expression or where?
>>If you are as "cautious" as people working with cryptography you would
>>start wondering if this is sign of a deeper malaise. :-)
>>As the great Cato said: I still feel that calling the function grep is
>>Could someone send a real problem to experiment on? Especially one
>>which the current regexp module is definitely too slow on.
> The reason I want pcre support, at least for my own personal sandbox, is
> because of features that the regexp library lacks. Not because of
> performance. Additionally, if there is a bug in pcre, chances are it
> will be fixed more soon than a bug in the erlang regex module(aside from
> just doing the work myself, which is fine I guess). Also the reason I
> asked about bifs and drivers is to solicit feedback from the list as to
> what the best way to implement a binding into the pcre library and what
> the drawbacks were of each implementation.
> I think this is a good discussion, not sure what everyone else thinks.
> Especially to show that erl bifs are fairly easy to implement, and the
> constraints that their implementation should adhere to.
More information about the erlang-questions