Talk:Perl Compatible Regular Expressions

From Wikipedia, the free encyclopedia

Shouldn't it be "Perl"?

Shouldn't what be "Perl"?

Contents

[edit] Misnomer

From the article:

The name is a misnomer, because Perl's regular expressions permit embedded Perl code during matching and replacing, so to be truly "Perl Compatible" would need a full Perl interpreter embedded in the library. PCRE contains no such interpreter.

Um...it's not a misnomer. The regular expressions of PCRE are compatible with Perl's. Embedded source code does not constitute a "regular expression pattern". 70.20.145.231 19:57, 26 November 2005 (UTC)

No, they're not entirely exactly compatible. Embedded Perl source code is considered part of the regular expression in Perl. PCRE will always do things that Perl can't, and vice versa. Randal L. Schwartz 21:27, 26 November 2005 (UTC)
I disagree its a misnomer. PCRE deliberately tries to be feature compatible with Perl. And at least recently Perl has tried to become feature compatible with PCRE. The fact is that in Perl 5.9.x active efforts have been made to make Perl support the PCRE syntax extensions, and in PCRE 7.x Philip has made active efforts to keep pace with new features being added to Perl 5.9.x. Also, I think that the whole quibble about (??{}) is unreasonable. In all production versions of Perl the feature is marked experimental, and I dont feel that supporting experimental features is required for compatibility. Do we expect PCRE to maintain bug compatibility as well? Demerphq 18:59, 14 May 2007 (UTC)

That's a very silly thing to put in an encyclopaedia article in that way. It sounds like a silly sling against PCRE. Nothing is compatible with anything. Come on. 208.115.233.109 14:47, 23 March 2007 (UTC)

I cannot be bothered to analyze the above, but there's something wrong with this part of the article right now. It says The name is therefore a misnomer, because PCRE is "Perl Compatible" only if [...]. The "therefore" appears to be a back-reference (pun intended) to a part that goes [PCRE] is much more powerful and flexible than POSIX regular expressions.. And that doesn't make sense, because the same applies to Perl REs. JöG 10:58, 5 July 2007 (UTC)

[edit] PCRE_EXTENDED

Need described on article?

See "CONDITIONAL SUBPATTERNS".

[edit] Recursive expressions

To Randal and anyone else interested: we say:

PCRE has developed a unique feature set, which in some cases includes features not yet available even in Perl's regular expression engine. For example, recursive subpatterns will be a feature of an upcoming 2006 release of Perl 5, but are already available in PCRE

Our citation for this is the PCRE manual which says:

Fairly obviously, PCRE does not support the (?{code}) and (??{code}) constructions. However, there is support for recursive patterns. This is not available in Perl 5.8, but will be in Perl 5.10.

This is pretty clear. PCRE doesn't support Perl's inline code ala ?{print "foo"} or ??{$regexp}, but does support recursive subexpressions, a feature which is being added to 5.10. I've been following this in Perl and PCRE, so I'm pretty sure of this. -Harmil 00:09, 14 February 2007 (UTC)

As an example of how PCRE and Perl regex are different, it's a bad example. Perhaps a simpler example that isn't so convoluted to explain would be handy. --Randal L. Schwartz 21:12, 16 February 2007 (UTC)
Ok, rather than trying to expand and clarify the example to the point of distracting from the topic at hand, I've extracted the example and simply put the conclusion in: the development of new features in both languages is coordinated, but unique. I think that sums up the situation, and is supported by the ref, without getting bogged down. I still think that the recursive sub-pattern feature (while it can be emulated by variable or code interpolation via ?{...} and ??{...}) is distinct and unique, but if there's a debate to be had around it, Wikipedia's not the place to have that debate, so I'll stand down. -Harmil 21:33, 16 February 2007 (UTC)

[edit] Distinction between syntax and implementation

I think the problem with this article is that it merges PCRE as a syntax with the PCRE library. A regular expression dialect is IMO generally considered to be "Perl Compatible" if it follows the general syntax that Larry Wall devised for Perl with such features as the consistant escaping rules and the (?...) notation for special patterns, particularly (?:...) for noncapturing grouping. The PCRE library is therefore just one of several Perl compatible regular expression engines, albeit the most widely used in other software.

I think distinguishing the two would make things clearer. It also would make it easier to explain that various implementations have influenced each other in terms of syntax. For instance PCRE 7 supports the .NET syntax for named buffer declaration as Perl 5.9.x has decided to support both the .NET syntax and the Python syntax. Similarly features from a Java "perl compatible" regular expression engine have been added to Perl 5.9.x and therefore also added to PCRE 7, vice versa features that first saw implementation in PCRE 7 have now been added to Perl 5.9.x. Demerphq 19:56, 14 May 2007 (UTC)

[edit] Programs that use PCRE / Language bindings for PCRE

I've started this section so that authors of programs, libraries, frameworks, language bindings, etc that use PCRE can highlight that fact here. I do this primarily because I don't think the author of such a program should be editing the primary entry as they have a vested interest in the subject. Adding the entry here allows the author to make editors of the page aware programs or projects that may be relevant, and allow an unbiased third party to update the main entry as appropriate.

Project: RegexKit url: http://regexkit.sourceforge.net/ Description: An Objective-C Framework for Regular Expressions using the PCRE Library for Mac OS X Cocoa and GNUstep. License: BSD. Language: Objective-C. —Preceding unsigned comment added by 205.150.102.219 (talk) 23:40, 26 January 2008 (UTC)