Re: [pcre-dev] Partial match at end of subject

Páxina inicial
Borrar esta mensaxe
Autor: ND
Data:  
Para: Pcre-dev
Asunto: Re: [pcre-dev] Partial match at end of subject
On 2019-07-24 15:51, ph10 wrote:

> If I understand you correctly, your proposal would mean that every
> non-anchored pattern would give a partial, empty-string, hard partial
> match at the end of a non-matching segment, and never return "no match".


Yes. And I like this idea.
With it we could operate in terms of matching a WHOLE subject that is
definitely exactly what we are interesting in.

When current segment can't brings us neither "match", nor "no match"
information about whole subject, then result is "indefinite" (this is a
true
meaning of thing that we now called "partial hard match"). In this
"indefinite" situation we
wants to know only one thing: what part of current subject must be keeped
and afterwards joined to next segment.


> I do not like this idea. This is how I see it:
>


I understand your idea. It replaces a true goal (matching a whole subject)
with auxiliary goal that we sure will lead us to the ultimate one. This
auxiliary goal don't worry directly about whole
subject matching but worry about can or not current segment be part of a
match. But getting definitely answer to this question is quite difficult
due to some "tricky" usecases. And I guess now we take into account not
all possible cases. And I don't sure that we can easily take it all.
But imagine that we definitely detect that current segment can't be part
of a match. Now we must additionally find out: is that due to whole
subject no match or not. So user must check after each "no match", is the
"no match" false-commit or is pattern anchored.

So to achieve those auxiliary goal we brings complexity to understanding,
docs and code. After every nomatch we force user to do what he could not
do.

But all this complexity is not needed as we don't try to find answer to
the question: can or not current segment be part of a match.


PS
And some bad things are happen now due to max_lookbehind. But it's beyond
my strength to write so large english texts at once. May be after we get
acceptable decision in this topic...