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.)
>
> I think the biggest problem with your idea is that it requires the
> engine to keep looking even after it finds a match, to see if there's
> another shorter match. This would make *every* match much much
> slower, potentially heatdeathoftheuniverse slower.
>
> I like the current semantics because it's very easy to visualize the
> engine acting on your instructions and stopping as soon as it finds a
> match. I am a programmer, and I prefer programs to descriptions.
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 find the first match as the current engine
does, then search for the smallest possible match WITHIN that first match.
Since it will already be as short as possible from the starting point, this
amounts to advancing the starting point as far as possible without changing
the ending point, as long as it still matches.
Deven
