Larry Wall <[EMAIL PROTECTED]> writes:
> Mark-Jason Dominus writes:
> : It may turn out that the new notation really does have exactly the
> : same ambiguities, but that's not clear to me now. All I said was that
> : I would like to see some discussion of it.
>
> Operator vs term processing wou
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Behavior of empty regex should be simple
=head1 VERSION
Maintainer: Mark Dominus <[EMAIL PROTECTED]>
Date: 24 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 144
=head1 ABSTRACT
=
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Brace-matching for Perl Regular Expressions
=head1 VERSION
Maintainer: Eric J. Roode <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 145
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend regex syntax to provide for return of a hash of matched subpatterns
=head1 VERSION
Maintainer: Kevin Walker <[EMAIL PROTECTED]>
Date: 23 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version:
> What exactly is matched by \g and \G is controlled by two new special
> variables, @^g and @^G, which are arrays of strings.
These sorts of global variables have been a problem in the past.
Since they change the meaning of the \g and \G escapes, I think they
should be pragmas or some other de
Mark Dominus <[EMAIL PROTECTED]>:
>
> This behavior should be changed. If the PATTERN is empty, Perl should
> look for the empty string. (That is, if the PATTERN is empty, it
> should always match.)
Except perhaps for undef loperands? (matchees? bindees?)
--
John Porter
>
>> What exactly is matched by \g and \G is controlled by two new special
>> variables, @^g and @^G, which are arrays of strings.
>
>These sorts of global variables have been a problem in the past.
>Since they change the meaning of the \g and \G escapes, I think they
>should be pragmas or some o
At 12:13 PM -0400 on 8/24/00, Mark-Jason Dominus wrote:
>The big problem I see that you didn't address is that you didn't say
>what would happen when the target string contains mismatched
>parentheses.
>
>Your example was:
>
>$string = "([b - (a + 1)] * 7)";
>$string =~ /\g.*?\G/;
>
>Now
> >I propose that this 'last successful match' behavior be discarded
> >entirely, and that an empty pattern always match the empty string.
>
> I don't see a consideration for simply s/successful// above, which
> has also been talked about.
Thanks, I will add this to the next version. I did c
>Thanks, I will add this to the next version. I did consider that, and
>I rejected it. Here's my thinking: s/successful// does make the
>feature somewhat more useful, but (a) all those uses are more easily
>accomplished with qr() these days, and (b) it's still an
>action-at-a-distance effect, wh
>How about \p and \P ("P" for "pairwise groupings" or just "pairs")?
I'm afraid those are taken, too.
Symbol Atomic Meaning
-- -- ---
C<\0> yes Match the null character (ASCII NUL).
C<\I> yes Match the character given in octal, up to C<
>
>> How about \p and \P ("P" for "pairwise groupings" or just "pairs")?
>
>\p and \P already have meanings in Perl 5 also. \p{property} matches
>any single character with the specified Unicode property, and
>\P{property} is the inverse.
Crap. Okay, that's it. Perl is just gonna have to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regex: Support for incremental pattern matching
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 11 August 2000
Last Modified: 24 August 2000
Version: 2
Mailing List: [EMAIL PROT
Damian Conway <[EMAIL PROTECTED]>:
>
> It is proposed that the Perl 6 regular expression engine be extended to
> allow a regex to match against an incremental character source, rather than
> only against a fixed string.
>
> Specifically, it is proposed that a subroutine reference could be bound
- Original Message -
From: "Eric Roode" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 24, 2000 1:56 PM
Subject: Re: RFC 145 (v1) Brace-matching for Perl Regular Expressions
> Well, if we stick to the model of a lowercase/uppercase pair
> for this proposed feature,
One thing I'd like to see is being able to specify qr//d regexes or list
(refs) within this, to be able to give multiple equivlent objects. For
example, the list
("<<" => ">>", "\N{left gimmulet}" => "\N{right gimmulet}") would allow <<
to match >> and « to match ». However, (["<<", "\N{left gim
Nathan Wiger wrote:
>
> > : =~ has no real world equivalent, and in fact I don't know how to
> > : pronounce it in English so that $x =~ /a/ makes sense.
> >
> > Yes, that's all pretty much on the mark.
>
> Not true, IMO. In math, =~ is used to indicate "rough equivalence".
> (Actually, the ~ go
Nathan Wiger writes:
>$x =~ /a/; # $x is roughly equivalent to a
I've been going at high speed through this thread, but has
anyone mentioned:
m{$foo}{^baz.*bar$}i
s{$foo}{(\w+) \1}{$1}g
With the first part of m{} and s{} containing an expression.
We lose !~ there, though.
Thoughts o
Nathan Torkington wrote:
>
> Nathan Wiger writes:
> >$x =~ /a/; # $x is roughly equivalent to a
>
> I've been going at high speed through this thread, but has
> anyone mentioned:
>
> m{$foo}{^baz.*bar$}i
> s{$foo}{(\w+) \1}{$1}g
>
> With the first part of m{} and s{} containing an ex
> > eq and ne are far more confusing.
>
> Hm. I've never had problems with this, although it does confuse me to go
> back to the shell's [ ] (aka test) and have them be backwards.
Yeah, I've got them finally sorted out, it only took me about 5 years...
;-P
> >if ( $x == m/stuff/ ) { ... }
>
>I propose that this 'last successful match' behavior be discarded
>entirely, and that an empty pattern always match the empty string.
I don't see a consideration for simply s/successful// above, which
has also been talked about. Thas would also match expected usage
based upon existing editors.
>=head1 ABSTRACT
>It is quite difficult to match paired characters in Perl 5 regular
>expressions. A solution is proposed, using new \g (match opening grouping
>character) and \G (match closing grouping character) metacharacters.
>Two new special variables, @^g and @^G control which strings are
This is useful in that it would stop being number dependent.
For example, you can't now safely say
/$var (foo) \1/
and guarantee for arbitrary contents of $var that your you have
the right number backref anymore.
If I recall correctly, the Python folks addressed this. One
might check tha
At 11:23 AM -0600 on 8/24/00, Tom Christiansen wrote:
>This is useful in that it would stop being number dependent.
>For example, you can't now safely say
>
>/$var (foo) \1/
>
>and guarantee for arbitrary contents of $var that your you have
>the right number backref anymore.
Good point. Tha
24 matches
Mail list logo
