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

[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 <ok@REDACTED> 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
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>