[PATCH pod/perlre.pod] 'Experimental constructs'
Abigail
A couple of regexp constructs are marked "highly experimental", and
"can be removed without further notice". However, they have been around
unmodified (except perhaps some bugfixes) since 5.6.0, and are commonly
used constructs.
I think it's time we remove the classification of "highly experimental".
Hence the following patch.
Abigail
--- pod/perlre.pod.orig Tue Oct 14 14:19:10 2003
+++ pod/perlre.pod Tue Oct 14 14:22:14 2003
@@ -449,12 +449,6 @@
the parentheses. The character after the question mark indicates
the extension.
-The stability of these extensions varies widely. Some have been
-part of the core language for many years. Others are experimental
-and may change without warning or be completely removed. Check
-the documentation on an individual feature to verify its current
-status.
-
A question mark was chosen for this and for the minimal-matching
construct because 1) question marks are rare in older regular
expressions, and 2) whenever you see one, you should stop and
@@ -559,9 +553,6 @@
=item C<(?{ code })>
-B<WARNING>: This extended regular expression feature is considered
-highly experimental, and may be changed or deleted without notice.
-
This zero-width assertion evaluates any embedded Perl code. It
always succeeds, and its C<code> is not interpolated. Currently,
the rules to determine where the C<code> ends are somewhat convoluted.
@@ -629,11 +620,6 @@
=item C<(??{ code })>
-B<WARNING>: This extended regular expression feature is considered
-highly experimental, and may be changed or deleted without notice.
-A simplified version of the syntax may be introduced for commonly
-used idioms.
-
This is a "postponed" regular subexpression. The C<code> is evaluated
at run time, at the moment this subexpression may match. The result
of evaluation is considered as a regular expression and matched as
@@ -656,9 +642,6 @@
=item C<< (?>pattern) >>
-B<WARNING>: This extended regular expression feature is considered
-highly experimental, and may be changed or deleted without notice.
-
An "independent" subexpression, one which matches the substring
that a I<standalone> C<pattern> would match if anchored at the given
position, and it matches I<nothing other than this substring>. This
@@ -751,9 +734,6 @@
=item C<(?(condition)yes-pattern)>
-B<WARNING>: This extended regular expression feature is considered
-highly experimental, and may be changed or deleted without notice.
-
Conditional expression. C<(condition)> should be either an integer in
parentheses (which is valid if the corresponding pair of parentheses
matched), or look-ahead/look-behind/evaluate zero-width assertion.
Dave Mitchell
>
> A couple of regexp constructs are marked "highly experimental", and
> "can be removed without further notice". However, they have been around
> unmodified (except perhaps some bugfixes) since 5.6.0, and are commonly
> used constructs.
>
> I think it's time we remove the classification of "highly experimental".
> Hence the following patch.
All the regex extensions that call Perl code are still deeply buggy as
regards scope (especially of lexical vars), and have a tendency to
coredump. Both Hugo and I have starry-eyed dreams of fixing these one day,
and any such fix may well change the semantics. So I think they should
remain marked as experimental.
--
You live and learn (although usually you just live).
h...@crypt.org
:On Tue, Oct 14, 2003 at 02:28:02PM +0200, Abigail wrote:
:>
:> A couple of regexp constructs are marked "highly experimental", and
:> "can be removed without further notice". However, they have been around
:> unmodified (except perhaps some bugfixes) since 5.6.0, and are commonly
:> used constructs.
:>
:> I think it's time we remove the classification of "highly experimental".
:> Hence the following patch.
:
:All the regex extensions that call Perl code are still deeply buggy as
:regards scope (especially of lexical vars), and have a tendency to
:coredump. Both Hugo and I have starry-eyed dreams of fixing these one day,
:and any such fix may well change the semantics. So I think they should
:remain marked as experimental.
Couldn't have said it better myself.
I do hope to clarify the status of these extensions for 5.10, but I want
to be confident that we have well defined semantics that we know how to
implement before doing so, and we're not there yet.
Hugo