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
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.
>
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.
> >
&g
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, 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 ar
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
>
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 behavio
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)/; # "ddd
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 wo
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 y
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 curr
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 rul
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
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
&
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
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:
> >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
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?
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
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
[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
Everyone:
I'm sorry about the recent commotion over minor aspects of regex design and
implementation. I stumbled into being the most active participant in an
argument nobody wanted, myself included. I realized too late (and with the
help of a friend) that I had been arguing for a _declarative_
I don't know if this has been discussed before, but I'm just tossing this
idea on the table for discussion and consideration. (If this was already
discussed, please tell me what the conclusion was, if any.)
How about implementing the Perl 6 compiler in Perl 6 itself?
Note that I'm _not_ talking
On Fri, 22 Dec 2000, Dan Sugalski wrote:
> At 02:43 PM 12/22/00 -0500, Deven T. Corzine wrote:
> >I don't know if this has been discussed before, but I'm just tossing this
> >idea on the table for discussion and consideration. (If this was already
> >dis
Can the autovivication behavior be changed slightly for Perl 6?
Specificly, can we suppress autovivication in read-only circumstances, and
evaluate the expression as "undef" immediately instead of autovivicating
empty data structures that didn't exist before?
The current behavior in Perl 5 is i
On Fri, 22 Dec 2000, Nicholas Clark wrote:
> On Fri, Dec 22, 2000 at 03:56:06PM -0500, Deven T. Corzine wrote:
> > Except for obvious performance-critical bottleneck areas, what advantages
> > are there to implementing anything else first in C?
>
> One reason (maybe not a
On Sat, 23 Dec 2000, Graham Barr wrote:
> This has been discussed on p5p many many times. And many times
> I have agreed with what you wrote. However one thing you did not mention,
> but does need to be considered is
>
> func($x{1}{2}{3})
>
> at this point you do not know if this is a read o
Yeah, you're thinking along the same lines as I was. Unfortunately, there
needs to be consensus about whether this behavior should be changed before
it can be implemented -- any idea how to make that come about?
Deven
On Sun, 21 Jan 2001, David L. Nicol wrote:
> "Deven T. C
On Mon, 5 Aug 2002, Dan Sugalski wrote:
> At 1:30 PM +1000 8/6/02, Damian Conway wrote:
> >Luke Palmer asked:
> >
> >>Does:
> >>
> >> print %foo{bar}{baz};
> >>
> >>still create %foo{bar} as a hashref if it doesn't exist?
> >
> >It is my very strong hope that it will not.
>
> Unless Larry de
On Tue, 13 Aug 2002, Larry Wall wrote:
> On Tue, 13 Aug 2002, Deven T. Corzine wrote:
> : However, will the "func($x{1}{2}{3})" case cause an implementation problem?
>
> This is why the new function type signatures will assume that
> parameters are constant. If you wa
On Tue, 13 Aug 2002, Nicholas Clark wrote:
> On Tue, Aug 13, 2002 at 03:06:40PM -0400, Deven T. Corzine wrote:
>
> > The only accurate way to know if the code modifies the variables is to do
> > some sort of dataflow analysis, and it can't be 100% accurate even then.
On Wed, 14 Aug 2002, Luke Palmer wrote:
> Why? We could make arglists exactly equivilent to the way they're done in
> Perl 5, which is a good way.
>
> sub foo($a, $b, *@c) {...}
>
> Would be exactly equivilent to Perl 5's
>
> sub foo { my ($a, $b, @c) = @_; ... }
I've got anothe
On Thu, 15 Aug 2002, Larry Wall wrote:
> On Thu, 15 Aug 2002, Deven T. Corzine wrote:
> : I've got another idea. How about using a copy-restore technique?
>
> I suspect that would make Perl 6's sub calls even slower than Perl 5's.
Yes and no.
For the normal case (p
I have no objection to pattern operators like ::: in principle, but I do
have a potential concern about them.
Given that the operators are actually defined in terms of "backtracking"
within the RE engine, does this constrain the implementation such that it
MUST be a backtracking implementation
On 28 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Deven T. Corzine) writes:
> > Would it be _possible_ to create a non-backtracking implementation of a
> > Perl 6 pattern engine
>
> I don't believe that it is, but not just because of : and friends.
> Why do
On Wed, 28 Aug 2002, Dan Sugalski wrote:
> At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote:
> >Would it be _possible_ to create a non-backtracking implementation of a
> >Perl 6 pattern engine, or does the existence of backtracking-related
> >operators preclude this p
Re: [perl6-language] Does ::: constrain the pattern engine implementation?
On Wed, 28 Aug 2002, Dan Sugalski wrote:
> A medium-term goal for the regex engine is to note where a DFA would give
> correct behaviour and use one, rather than going through the more
> expensive generalized regex engi
On Wed, 28 Aug 2002, Larry Wall wrote:
> : (1) Can we have a ":study" modifier in Perl 6 for patterns?
> :
> : It could be a no-op if necessary, but it could take the place of Perl 5's
> : "study" operator and indicate that the programmer WANTS the pattern
> : optimized for maximum runtime spe
On Wed, 28 Aug 2002, Larry Wall wrote:
> That is a worthy consideration, but expressiveness takes precedence
> over it in this case.
I see nothing wrong with expressiveness taking precedence -- I'm only
saying that it would be best to be cognizant of any restrictions we're
hardcoding into the
On Wed, 28 Aug 2002, Steve Fink wrote:
> On Wed, Aug 28, 2002 at 12:55:44PM -0400, Deven T. Corzine wrote:
> > On Wed, 28 Aug 2002, Dan Sugalski wrote:
> > > At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote:
> >
> > On the other hand, :, ::, ::: and don't ne
Dan Sugalski wrote:
Last chance to get in comments on the first half of the proposal. If
it looks adequate, I'll put together the technical details (functions,
protocols, structures, and whatnot) and send that off for
abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and
get the
Dan Sugalski wrote:
At 5:24 PM -0500 1/22/04, Deven T. Corzine wrote:
Damian's issues were addressed before he brought them up, though not
in one spot.
A single global lock, like python and ruby use, kill any hope of
SMP-ability.
Hand-rolled threading has unpleasant complexity issues,
# New Ticket Created by "Deven T. Corzine"
# Please include the string: [perl #56050]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56050 >
I
# New Ticket Created by "Deven T. Corzine"
# Please include the string: [perl #56048]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56048 >
I checked Parrot out of Subversion on my Windows laptop with
Torto
49 matches
Mail list logo
