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 "bccccd" is a more intuitive
> >match than "bbbbccccd". That was the matching text, not the regexp, sorry
> >if I didn't make that clear.
>
> Fine. What you said is
>
> first
> find a b
> then
> find any non-newline, repeated 0 to N times
> then
> find a d
>
> What part of "first find a b" do you expect a randomizing solution to?
> That's very clear.
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. I'm aware of the mapping from the
pattern to the procedure, but I'm retaining in mind the original intent of
the pattern as well as the details of how it's matched. The semantics of
the step-by-step procedure are very similar to those of the pattern, but
not identical.
The semantics I want it to mean are "find a match starting with b, ending
with d, with as little as necessary in between". The difference between
this and the procedural description you give above is what I'm talking
about where we're losing something of the gestalt of the whole. While it's
similar, it's not quite the same.
Deven
