I can see the motivation for wanting this, but there's a cost I
haven't read anyone mentioning yet: this is abandoning backward
compatibility with a regex notation that has remained pretty
consistent in ed(1) and grep(1) and things inspired by them since I
guess the early '70s, when they were born.
It may be we want to pay that price, but do please comment on it in
the RFC, it needs to be on the table. Perl is a prodigiously rich
language, and in large part it avoids the problem made famous by
PL/1, of being nearly impossible to learn completely, by the amount
that it borrows from other familiar tools.
Up until now, a wizard with regexps can carry all their knowlege
forward; everything they've done in the past keeps working
identically, and regexps composed for most other engines work fine
in perl. There's always some differences between engines; some
require (...) for grouping and/or tagging, others require \(...\);
some support "|" for alternation, some support "+" for "one or
more", some support "?" for "zero or one", and like that. And of
course perl has some heroic extensions. But using \1 for backrefs
within a pattern match has been standard; if an engine can match the
likes of beriberi and murmur, it might demand ^\(.*\)\1$ or it might
prefer ^(.*)\1$, but the \1 at least has been consistent. The
further we wander from supporting the same regexp languages (as a
subset of ours) as the other popular engines, the more support work
we're making for ourselves.
-Bennett
PGP signature
