[erlang-questions] builtin regexp functions in Erlang/OTP R12B-3

Robert Virding <>
Mon Jun 16 16:15:59 CEST 2008

All I can say is that I agree with Richard but expand more on it the EEP.
One quick comment is that I wonder if not part of the problem with PCRE and
Perl regular expressions is that in one respect they are integrated into
Perl and contain features to interact with the rest of Perl. If I remember
correctly, for example, you can set Perl variables directly from the RE. Is
this what became the named subexprs in PCRE?


2008/6/16 Kenneth Lundin <>:

> Hi,
> Regarding the new "experimental" builtin regexp functions in the re
> module our intention is
> to provide a fully working implementation where we want feedback on
> the API functions and also other feedback.
> With "experimental" we don't mean very buggy or low quality but rather
> that the API's are not stabilized yet and that there
> are a few optimizations more to do.
> Our intention with releasing this regexp implementation before the
> API's are 100% settled is that we believe
> we can get more and better comments if people actuall can try
> themselves to use the functions.
> We would appreciate if we get the comments in relation to the
> EEP 11 Built in regular expressions in Erlang
> http://www.erlang.org/eeps/eep-0011.html which is especially written
> for this purpose.
> /Regards Kenneth Lundin Erlang/OTP team at Ericsson
> On Mon, Jun 16, 2008 at 2:03 AM, Richard A. O'Keefe <>
> wrote:
> > The README for OTP R12B-3 has says, amongst good stuff:
> > OTP-7181 An experimental module "re" is added to the emulator
> >   which interfacesa publicly available regular expression library
> >   for Perl-like regular expressions (PCRE). The interface is purely
> >   experimental and *will* be subject to change.
> > One way I hope that it will change is that it won't be PCRE.
> > There are two major problems with Perl regular expressions:
> > (A) the design is so bloated that it is extraordinarily hard for
> >     people to master them.  This is in marked contrast to the
> >     wise restraint of POSIX "Extended Regular Expressions".
> > (B) the design is so bloated that they completely miss the whole
> >     point of using regular expressions in the first place, which
> >     is LINEAR-TIME MATCHING.  True, there are some cases where
> >     Perl (and PCRE) take exponential time when they could take
> >     linear time, but I'm not talking about accidents of the
> >     implementation.  The design-by-elephantiasis approach has
> >     resulted in a matching language which is provably intractable.
> >
> > One of the reasons for (A) is that it is very hard for anyone not
> > intimately familiar with the Perl or PCRE implementation to tell
> > which patterns will be matched efficiently and which will not.
> > There are free implementations of Posix EREs out there that do
> > guarantee matching linear in the amount of data matched, so any
> > RE library for Erlang built on top of C should use such a library
> > whenever possible, falling back on PCRE only when absolutely
> > necessary.
> > This has been discussed at length in this mailing list before.
> >
> > _______________________________________________
> > erlang-questions mailing list
> > 
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080616/bb362e02/attachment.html>

More information about the erlang-questions mailing list