Non-greedy matching is a very valuable Perl 5 regular expression feature
that simplifies many regular expressions. However, early on I discovered
what seems to be a failure of the mechanism -- matches were MORE greedy
than necessary. I'm not sure if other people noticed this, or just failed
to c
>Does anyone disagree with the premise, and believe that "d" is the
>CORRECT match for the non-greedy regexp above?
Yes. The Camel's regex chapter reads:
You might say that eagerness holds priority over greed (or thrift).
>For what it's worth, here's a quote from a Perl 5.005_03 "p
On Dec 14, Deven T. Corzine said:
>The crux of the problem is that non-greedy qualifiers don't affect the
>"earliest match" behavior, which makes the matches more greedy than they
>really ought to be.
That's because "greediness" is just a measure of crawl vs. backtrack. The
regex /a.*b/ will ma
On Thu, 14 Dec 2000, Tom Christiansen wrote:
> >Does anyone disagree with the premise, and believe that "d" is the
> >CORRECT match for the non-greedy regexp above?
>
> Yes. The Camel's regex chapter reads:
>
> You might say that eagerness holds priority over greed (or thrift).
N
On Thu, 14 Dec 2000, Jeff Pinyan wrote:
> On Dec 14, Deven T. Corzine said:
>
> >The crux of the problem is that non-greedy qualifiers don't affect the
> >"earliest match" behavior, which makes the matches more greedy than they
> >really ought to be.
>
> That's because "greediness" is just a m
On Dec 14, Deven T. Corzine said:
>> You're asking for something like
>>
>> /(?>
>> which is an "optimization" you'll have to incorporate on your own.
>
>Thanks for the example. Unfortunately, your attempted workaround doesn't
>even work for the example string; the "a" preceding "d"
On Thu, 14 Dec 2000, Jeff Pinyan wrote:
> On Dec 14, Deven T. Corzine said:
>
> >> You're asking for something like
> >>
> >> /(? >>
> >> which is an "optimization" you'll have to incorporate on your own.
> >
> >Thanks for the example. Unfortunately, your attempted workaround doesn't
> >ev
Deven T. Corzine writes:
> I haven't even SEEN an example where the current behavior is actually
> preferable than my proposed behavior, have you? (And I'd expect at least a
> FEW, though I suspect there are probably more counterexamples.)
I think the biggest problem with your idea is that it re
On Thu, Dec 14, 2000 at 04:19:15PM -0700, Nathan Torkington wrote:
> Deven T. Corzine writes:
> > I haven't even SEEN an example where the current behavior is actually
> > preferable than my proposed behavior, have you? (And I'd expect at least a
> > FEW, though I suspect there are probably more
Jarkko Hietaniemi writes:
> Couldn't the be an option (a modifier) to do this? Then if someone
> asks to wait until all the electrons spin down, so be it...
Only if we can get MjD's wordy regex modifiers:
/a.*?b/{heatdeath}
Nat :-)
>No question that's how it's been implemented. But WHY would anyone want
>such behavior? When is it beneficial?
It is beneficial because this is how it's always been, because it
is faster, because it is more expressive, because it is more powerful,
because it is more intuitive, and because it i
> "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
Deven> I'm not pushing for this to be fixed in Perl 5; it's been out
Deven> there long enough, and there's no point worrying about it in
Deven> that version. But that doesn't mean that the same design flaw
Deven> should be kept in Perl
> "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
Deven> I haven't even SEEN an example where the current behavior is
Deven> actually preferable than my proposed behavior, have you? (And
Deven> I'd expect at least a FEW, though I suspect there are probably
Deven> more counterexamples.
>The crux of the problem is that non-greedy qualifiers don't affect the
>"earliest match" behavior, which makes the matches more greedy than they
>really ought to be.
>
>Here is a simple example: (tested with perl 5.005_03)
>
> $_ = "";
> ($greedy) = /(b.*d)/;
On Dec 14, Randal L. Schwartz said:
>Deven> I haven't even SEEN an example where the current behavior is
>Deven> actually preferable than my proposed behavior, have you? (And
>Deven> I'd expect at least a FEW, though I suspect there are probably
>Deven> more counterexamples.)
>
>If I want the le
Oh, my. I fear I may have ruffled some feathers here. I apologize; I was
hoping to spark a debate, not a flame war. Could we all please take a step
back and cool off for a bit, and not let this get personal?
I'm afraid it may seem like I'm ranting about Perl 5's regular expressions,
when I onl
On Thu, Dec 14, 2000 at 04:10:12PM -0500, Deven T. Corzine wrote:
> The crux of the problem is that non-greedy qualifiers don't affect the
> "earliest match" behavior, which makes the matches more greedy than they
> really ought to be.
Right. We've got a terminoligy issue. There's two axes here:
On Thu, 14 Dec 2000, Deven T. Corzine wrote:
> Here is a simple example: (tested with perl 5.005_03)
>
> $_ = "";
> ($greedy) = /(b.*d)/; # "" (correct)
> ($non_greedy) = /(b.*?d)/; # "d" (should be "bd"!)
> Does an
On Thu, 14 Dec 2000, Nathan Torkington wrote:
> Deven T. Corzine writes:
> > I haven't even SEEN an example where the current behavior is actually
> > preferable than my proposed behavior, have you? (And I'd expect at least a
> > FEW, though I suspect there are probably more counterexamples.)
>
On Fri, Dec 15, 2000 at 01:13:13PM -0500, Deven T. Corzine wrote:
> Not at all. I don't want it to keep looking after it finds the first
> match. I want it to make sure that match isn't unnecessarily long, if
> non-greedy matching was in use. Conceptually (I don't think this would be
> a good i
On Fri, 15 Dec 2000, brian d foy wrote:
> On Thu, 14 Dec 2000, Deven T. Corzine wrote:
>
> > Here is a simple example: (tested with perl 5.005_03)
> >
> > $_ = "";
> > ($greedy) = /(b.*d)/; # "" (correct)
> > ($non_greedy) = /(b.*?d)/
On 14 Dec 2000, Randal L. Schwartz wrote:
> > "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
>
> Deven> I'm not pushing for this to be fixed in Perl 5; it's been out
> Deven> there long enough, and there's no point worrying about it in
> Deven> that version. But that doesn't mean t
On 14 Dec 2000, Randal L. Schwartz wrote:
> > "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
>
> Deven> I haven't even SEEN an example where the current behavior is
> Deven> actually preferable than my proposed behavior, have you? (And
> Deven> I'd expect at least a FEW, though I s
On Fri, 15 Dec 2000, Jonathan Scott Duff wrote:
> On Fri, Dec 15, 2000 at 01:13:13PM -0500, Deven T. Corzine wrote:
> > Not at all. I don't want it to keep looking after it finds the first
> > match. I want it to make sure that match isn't unnecessarily long, if
> > non-greedy matching was in
> "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
Deven> What surprised me was how vigorously people would defend the
Deven> status quo, and insist on the correctness of the current
Deven> behavior without thinking it through.
No, I thought it through quite completely. As have others
> "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
Deven> As for special-case rules, I believe that my proposed modification would
Deven> REMOVE a special-case semantic rule, at the cost of added complexity at the
Deven> implementation level. (The cost decision of whether that added co
> "DTC" == Deven T Corzine <[EMAIL PROTECTED]> writes:
DTC> The pattern in question is "b.*?d". Obviously, this matches "b",
DTC> followed by something else, followed by "d". What "something
DTC> else" should be is the issue at hand. That portion of the regexp
DTC> is just ".*?" -
On Thu, 14 Dec 2000, Jarkko Hietaniemi wrote:
> On Thu, Dec 14, 2000 at 04:19:15PM -0700, Nathan Torkington wrote:
> > Deven T. Corzine writes:
> > > I haven't even SEEN an example where the current behavior is actually
> > > preferable than my proposed behavior, have you? (And I'd expect at le
On 15 Dec 2000, Randal L. Schwartz wrote:
> > "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
>
> Deven> As for special-case rules, I believe that my proposed modification would
> Deven> REMOVE a special-case semantic rule, at the cost of added complexity at the
> Deven> implementati
On Thu, 14 Dec 2000, Jeff Pinyan wrote:
> You could use my sexeger technique to get this behavior (possibly):
>
> $string = "aaabbbcccdddeee";
> # regex to be reversed: /b(.*?)d/
> $revstr = reverse $string;
> ($match) = $revstr =~ /d(.*?)b/;
>
> No, that doesn't quite work. It works
On Thu, 14 Dec 2000, James Mastros wrote:
> On Thu, Dec 14, 2000 at 04:10:12PM -0500, Deven T. Corzine wrote:
> > The crux of the problem is that non-greedy qualifiers don't affect the
> > "earliest match" behavior, which makes the matches more greedy than they
> > really ought to be.
> Right.
On Fri, 15 Dec 2000, Deven T. Corzine wrote:
> Not at all. I don't want it to keep looking after it finds the first
> match. I want it to make sure that match isn't unnecessarily long, if
> non-greedy matching was in use. Conceptually (I don't think this would be
> a good implementation), you
Please give it a rest. I think everybody got it by now. Everybody
understands how the current implementation works and what the
semantics are, and you disagree with the current semantics. I think
that's the end of story since changing current default semantics is
simply not an option. We can't
"Deven T. Corzine" <[EMAIL PROTECTED]> writes:
>I've yet to see a concrete example of where the current behavior is
>helpful,
What about matching C comments?
($first_comment) = $code =~ m!(/\*.*?\*/)!s;
# (ignore issues with quoted strings in $code
Works correctly under the curre
> More generally, it seems to me that you're hung up on the description
> of "*?" as "shortest possible match". That's an ambiguous
Yup, that's a bit confusing. It's really "start matching as soon as
possible, and stop matching as soon as possible". (The usual greedy
one is, of course, "keep
On 15 Dec 2000, Randal L. Schwartz wrote:
> > "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
>
> Deven> What surprised me was how vigorously people would defend the
> Deven> status quo, and insist on the correctness of the current
> Deven> behavior without thinking it through.
>
>
>I made a mistake in phrasing it this way, because it seemed to suggest that
>I thought it was an implementation bug that it returns "d" instead
>of "bd". I didn't make it clear that I was trying to approach this as
>a purely SEMANTIC question, considered in isolation from the impleme
>As for special-case rules, I believe that my proposed modification would
>REMOVE a special-case semantic rule, at the cost of added complexity at the
>implementation level.
What is this alleged "special-case rule" you are talking about?
There is no such thing. None. When you write /pat/, it
On Fri, 15 Dec 2000, Jarkko Hietaniemi wrote:
> Please give it a rest. I think everybody got it by now. Everybody
> understands how the current implementation works and what the
> semantics are, and you disagree with the current semantics.
We may have to "agree to disagree". I'm understand w
>I meant that I've never seen
>a concrete, realistic example where the current behavior is more beneficial
>to the programmer than my proposed behavior.
Absense of evidence is hardly evidence of absence.
`cat /vmunix` =~ /\w+/
I just love guaranteed worst-case behavior. NOT.
It is good to
I wrote:
>More generally, it seems to me that you're hung up on the
>description of "*?" as "shortest possible match". That's an
>ambiguous simplification of what "*?" means. It might better be
>described as "match until you find a match for the rest of the
>regex" ('d' in your example). I
>I want the maximum level of OVERALL consistency for regular expressions as
We're there, thank you very much. "Find a match" is the over-riding
sentiment, the principle semantic. It is completely consistent with
this. You've got greed/nongreed very wrong.
>a whole, rather than immutable adhe
>Actually, I'm not sure -- it's conceivable that the ending point would ALSO
>move inward for a different starting point within the original match. But
>the ending point should NEVER be advanced further -- that's where the
>"leftmost over nongreedy" rule should apply instead...
Please show us yo
>> More generally, it seems to me that you're hung up on the description
>> of "*?" as "shortest possible match". That's an ambiguous
>Yup, that's a bit confusing. It's really "start matching as soon as
>possible, and stop matching as soon as possible". (The usual greedy
>one is, of course,
>Have you thought it through NOW, on a purely semantic level (in isolation
>from implementation issues and historical precedent),
I've said it before, and I'll say it again: you keep using
the word "semantic", but I do not think you know what that word means.
--tom
On Fri, 15 Dec 2000, Tom Christiansen wrote:
> >As for special-case rules, I believe that my proposed modification would
> >REMOVE a special-case semantic rule, at the cost of added complexity at the
> >implementation level.
>
> What is this alleged "special-case rule" you are talking about?
>Really? I haven't taken a survey, but I did ask one co-worker for his
>first impression of what the regexp (from my example) would match. Not
>being an experienced Perl programmer, but being familiar with regular
>expressions, he believed he understood the idea of non-greedy matching.
>His expe
On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
> Tell me how you can do that without breaking much existing code.
Pssst, Randal, this is Perl 6, not p5p.
--
"There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence." -
>We may have to "agree to disagree".
I shan't be doing that.
>I'm understand why people believe in
>the current semantics, but I've seen no indication that anyone else
>understands why I believe in these alternative semantics, or has tried.
>(Disagreeing with my conclusion doesn't preclude und
On Fri, 15 Dec 2000, Tom Christiansen wrote:
> >Actually, I'm not sure -- it's conceivable that the ending point would ALSO
> >move inward for a different starting point within the original match. But
> >the ending point should NEVER be advanced further -- that's where the
> >"leftmost over non
On Fri, 15 Dec 2000, Simon Cozens wrote:
> On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
> > Tell me how you can do that without breaking much existing code.
>
> Pssst, Randal, this is Perl 6, not p5p.
That's why I never suggested fixing it in Perl 5 -- the chance of brea
>On Fri, 15 Dec 2000, Tom Christiansen wrote:
>> >As for special-case rules, I believe that my proposed modification would
>> >REMOVE a special-case semantic rule, at the cost of added complexity at the
>> >implementation level.
>>
>> What is this alleged "special-case rule" you are talking ab
>You can't explain why "d" matches without making reference to the
>absolute priority of the leftmost rule. "bd" would still make sense
>(locally) without reference to that rule.
Nope. Nope, nope, and nope.
Th8is /d/ thing, which is completely unrealistic and
non-real-world
Tom Christiansen writes:
> >We may have to "agree to disagree".
>
> I shan't be doing that.
I think you should, or at least agree to take it private and report
back to the list once you both come to a decision. Once you've stated
your position twice, there's not really much point in saying it
On Fri, 15 Dec 2000, Tom Christiansen wrote:
> >We may have to "agree to disagree".
>
> I shan't be doing that.
Well, I'm still willing to discuss it, as long as it remains a discussion
and doesn't become a flame war.
> >I'm understand why people believe in
> >the current semantics, but I'v
On Fri, 15 Dec 2000, Nathan Torkington wrote:
> Tom Christiansen writes:
> > >We may have to "agree to disagree".
> >
> > I shan't be doing that.
>
> I think you should, or at least agree to take it private and report
> back to the list once you both come to a decision. Once you've stated
>
On Fri, 15 Dec 2000, Tom Christiansen wrote:
> >You can't explain why "d" matches without making reference to the
> >absolute priority of the leftmost rule. "bd" would still make sense
> >(locally) without reference to that rule.
>
> Nope. Nope, nope, and nope.
>
> Th8is /ccc
>That would be a strange regexp, but I never suggested it. I suggested the
>regexp /b.*?d/ and pointed out that I believe "bd" is a more intuitive
>match than "d". That was the matching text, not the regexp, sorry
>if I didn't make that clear.
Fine. What you said is
first
>At worst, this should take no more than double the amount of time that the
>single pass did, probably less. Hardly a cause to concern ourselves with
>the heat death of the universe.
Oh really? We have shown that for the kind of global overall
analysis that you are asking for, that in the gener
And while I'm at it, consider /(.*)(.*)(.*)/, which we'll call
/ABC./ You need to be able to say all of these independently
and in conjunction with one another:
whether segment A is longest or shortest overall
whether segment B is longest or shortest overall
whether segment C
On Fri, 15 Dec 2000, Tom Christiansen wrote:
> >That would be a strange regexp, but I never suggested it. I suggested the
> >regexp /b.*?d/ and pointed out that I believe "bd" is a more intuitive
> >match than "d". That was the matching text, not the regexp, sorry
> >if I didn't ma
Take. It. To. Private. Email. Please.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
On Fri, 15 Dec 2000, Tom Christiansen wrote:
> >At worst, this should take no more than double the amount of time that the
> >single pass did, probably less. Hardly a cause to concern ourselves with
> >the heat death of the universe.
>
> Oh really? We have shown that for the kind of global ov
>Take. It. To. Private. Email. Please.
I'm going to do better. I'm taking it to /dev/null.
It's not worth my wasting my life over. Nobody
agrees with this guy, so it doesn't matter.
--tom
On Fri, Dec 15, 2000 at 05:20:35PM -0500, Deven T. Corzine wrote:
> It's a pattern, not a program. Yes, it's straightforward to treat it as a
> step-by-step procedure for matching that pattern, but by doing so, you lose
> something of the gestalt of the whole.
You may deal in patterns, but com
[I delayed responding to this message because it was the longest.]
On Thu, 14 Dec 2000, Tom Christiansen wrote:
> >No question that's how it's been implemented. But WHY would anyone want
> >such behavior? When is it beneficial?
>
> It is beneficial because this is how it's always been, becaus
>Nice summary, but I'm not buying what you're selling in the elaboration.
Then you lose, because I am not allowed to disagree with you anymore.
And everyone else has already written you off.
And the answer to "what breaks if mimimal matching is overall but
maximal matching is local"--or even, "i
On Fri, 15 Dec 2000, Deven T. Corzine wrote:
> On 15 Dec 2000, Randal L. Schwartz wrote:
>
> > > "Deven" == Deven T Corzine <[EMAIL PROTECTED]> writes:
> >
> > Deven> As for special-case rules, I believe that my proposed modification would
> > Deven> REMOVE a special-case semantic rule, at
On Fri, 15 Dec 2000, Deven T. Corzine wrote:
> If we want the first interesting match, and we're preferring early matches
> and short matches, I believe that "bd" is more interesting.
then write a regex that describes that pattern. the pattern is
one b
followed by
On Fri, 15 Dec 2000, Simon Cozens wrote:
> On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
> > Tell me how you can do that without breaking much existing code.
>
> Pssst, Randal, this is Perl 6, not p5p.
well, we do have to translate 95% of that code to Perl 6 without a hitc
On Fri, 15 Dec 2000 13:42:44 -0700, Kevin Walker wrote:
>Deven seems to be advocating thinking about regular expressions
>without worrying too much about the implementation, even at a fairly
>abstract level.
Here's a counter example:
/dc/
Shouldn't a non-greed
71 matches
Mail list logo
