> :Anyway, Snobol has a nice heuristic to prevent infinite recursion in
> :cases like this, but I'm not sure it's applicable to the way the Perl
> :regex engine works. I will think about it.
>
> It is probably worth adding the heuristic above: anytime you recurse
> into the same re at the same
In <[EMAIL PROTECTED]>, Mark-Jason Dominus writes:
:
:> : it looks worse and dumps core.
:>
:> That's because the first non-paren forces it to recurse into the
:> second branch until you hit REG_INFTY or overflow the stack. Swap
:> second and third branches and you have a better chance:
:
:I thin
Peter Heslin writes:
:On Wed, Aug 30, 2000 at 11:54:29PM -0400, Mark-Jason Dominus wrote:
:> Perhaps Hugo van der Sanden
:> would be willing to discuss this with you in more detail?
:
:I am not acquainted with the gentleman you name. Please do solicit
:the input of others you know who might be in
> In theory, all letters should be reserved to map to future flags for
> the same reason.
My recollection is that Larry specifically mandated this, and that's
why (?p...) was changed to (??...) in 5.6.0.
> : it looks worse and dumps core.
>
> That's because the first non-paren forces it to recurse into the
> second branch until you hit REG_INFTY or overflow the stack. Swap
> second and third branches and you have a better chance:
I think something else goes wrong there too.
> $re = qr{...
mike mulligan replied to Peter Heslin:
:> Simply put, I want variable-length lookbehind.
:
:The RFC seems to say you want this so that you can optimize the operation of
:the regex execution. I've been looking at the existing fixed-length
:look-behind and see that it does not seem to operate the w
mike mulligan writes:
:If it important to be able to do both:
:
: $large = join '|', @possible'
: $data =~ / (?<= $large) GAAC /x; # Don't care which @possible?
:
:and
:
: $data =~ m/ ($large) GAAC /x; # Need $1 to say which @possible
:
:Then perhaps a back-reference-setting look-behind cou
Mark-Jason Dominus writes:
:> There's also long been talk/thought about making $& and $1
:> and friends magic aliases into the original string, which would
:> save that cost.
:
:Please correct me if I'm mistaken, but I believe that that's the way
:they are implemented now. A regex match populate
Mark-Jason Dominus wrote:
:This is not exactly the same, but I tried a direct translation:
:
: $re = qr{ \( (??{$re}) \)
: | (??{$re}) (??{$re})
: | (?> [^()]+)
: }x;
:
:and it looks worse and dumps core.
That's because the first non-paren forces it to recu
[resent, 'cos I can't spell "perl6"]
Richard Proctor wrote:
:The whole (?x set of thingies is getting complicated... The list of what is
:used at present (and in current suggestions is:
:
:Current Use in perl5
:
:(?# comment
:(?imsx flags
:(?-imsx flags
That's actually (?iogcmsx and (?-iog
Richard Proctor writes:
:On Fri 08 Sep, Kevin Walker wrote:
[...]
:> Tom's comment points out a shortcoming in the original RFC: There's
:> no way to make, by name, a backref to a named group. I propose to
:> fix that in a revised version of RFC 150. I don't have strong
:> feelings about wha
Nathan Wiger wrote:
>
> > RFC 145: Brace-matching for Perl Regular Expressions (Eric Roode)
> >
> > Nathan Wiger suggested a special syntax for matching XML-style
> > open and close tags.
>
> This died in favor of a more general brace-matching construct, ?[ and
> ?], which could be used in this
In <[EMAIL PROTECTED]>, Hugo writes:
:Apologies in advance for so rudely dumping this lot and _still_ not
:joining the list [...]
Ah, I've now discovered the archives, and seen that this list is not
so frighteningly busy as I had anticipated. Now joined.
Hugo
> RFC 145: Brace-matching for Perl Regular Expressions (Eric Roode)
>
> Nathan Wiger suggested a special syntax for matching XML-style
> open and close tags.
This died in favor of a more general brace-matching construct, ?[ and
?], which could be used in this capacity:
/(?['' => '')Stuff(?]
> I propose adding this note. His preference for the working of
> /t and /g seems the most appropriate. Unless I here any further
> discussion I propose moving this RFC to frozen this week.
Please post a complete, revised version of the RFC *before* you freeze it.
> > in any case, i think we have a fair agreement on rfc 158 and i will
> > freeze it if there is no further comments on it.
>
> I think you should remove the parts of your propsal about making $& be
> autolocalized.
If you're not planning to revise your RFC, let me know so that I can
perl6-language-regex
Summary report 2911
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
The author sent revised version of the RFC. There seem to be two ideas
here:
1. The lookbehind assertions should work for variable-length
patterns. (At
I have some trouble understanding just what the proposal is, since the
RFC doesn't contain any examples. But I gather that you want to usurp
*both* the (...) and the [...] notation for numeric ranges.
This would change the meaning of any code that happened to contain a
regex like this:
> (?@foo) is sort of equivalent to (??{join('|',@foo)}), ie it expands into a
> list of alternatives. One could possible use just @foo, for this.
It just occurs to me that this is already possible. I've written a
module, 'atq', such that if you write
use atq;
then your regexes may co
> I propose adding the first para as a note and moving RFC to frozen soon.
You did not address my points about tr///o and related issues.
I suggest that you submit a revised RFC and then freeze it a week
afterwards if there is still no discussion.
> As to your contention that "at best" (?r) will defeat many present
> optimizations, can you tell me why this will necessarily be so in the
> new engine?
Let me explain my thinking along these lines. I've made a number of
assumptions, which may not be correct, and certainly aren't obvious.
I
> Simply put, I want variable-length lookbehind.
Why didn't you simply propose that the (?<...) operator be fixed to
support variable-length expressions? Why so much additional machinery?
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
Last Modified: 11 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 1
Thinking about the brace matching problem, regarding the specific
problem of writing a regex to match any valid specification of
a scalar written like
${expression returning name or reference goes here}
I realized that no amount of lookahead is going to be without possible
problems.
Sorry, I can't help but read the subject as an abbreviation of
post Hugo, ergo propter Hugo
and then I wonder why you're naming an RFC after a logical fallacy
involving a perl5-porter. I am seeking treatment, though :-)
Nat
Hugo wrote:
> Definitely. Should be easy to implement. There is a potential for
> confusion, since it makes the tr/ lists look even more like
> m/ and s/ patterns, but I think it can only be less confusion than
> the current state of affairs. It is tempting to make it the default,
> and have a fla
This RFC had three concepts, I propose dropping the "Not a pattern" from here
as it is now in RFC 198 and the null element. The List expansion might
benefit from a slight enhancement.
Hugo:
> (?@foo) and (?Q@foo) are both things I've wanted before now. I'm
> not sure if this is the right syntax,
This list has gone a little quiet...
Hugo wrote:
> I like this too. I'd suggest /t should mean a) return a scalar of
> the number of matches and b) don't set any special variables. Then
> /t without /g would return 0 or 1, but be faster since no extra
> information need be captured (except intern
28 matches
Mail list logo
