Re: Row pattern recognition

>> Reluctant quantifiers seem to have important usecases (i.e. the
>> shortest path). But if implementation is too difficult, we should
>> defer to after the first version.
>>
>> How do you estimate the difficulty and the size of the code for
>> reluctant quantifiers?
>
> The core difficulty is not in nfa_advance() itself but in matched
> state replacement: once a greedy match is confirmed, replacing it
> with a shorter reluctant match requires updating matchedState, which
> the current structure does not support cleanly.
>
> This is the same design gap that underlies the altPriority FIXME:
> both problems require rethinking how the confirmed match state
> interacts with the active NFA state list. I think it is worth
> solving them together.

Agreed.

> I would prefer to work on the altPriority redesign first and include
> reluctant quantifiers and state pruning as part of that work if the
> design allows it cleanly.
>
> If I encounter design issues that are difficult to resolve, I will
> come back to discuss before proceeding.

Sounds like a perfect plan!

>> > - {- -} (exclusion)
>> > - Empty pattern -- A{0}, () empty pattern. Should we implement
>> > A{0} in this patch and defer empty match semantics (unmatch vs
>> > empty match distinction) to when MEASURE is implemented?
>>
>> Yes, I think so. We should defer.
>>
>> > - A{0}: proceed with implementation?
>> > - () empty pattern: also in scope, or defer?
>>
>> I think we can defer.
>
> Just to confirm: my understanding is that A{0} is in scope for this
> patch, while () empty pattern and empty match semantics are deferred.
> Is that correct? If so, I plan to implement A{0} together with the
> cycle detection fix for patterns like (A*)*, since both involve
> zero-length iteration handling.

Thanks for clarification. That's my understanding too.

>> I though we could defer after the first commit. Do you wish to
>> implement it now?
>> [regarding PERMUTE]
>
> I am happy to defer PERMUTE.

Ok.

>> 1-3 look good.
>
> I will address test reorganization and documentation review after the bug
> fixes and feature implementations are complete.

I can work on the documentation review part.

>> BTW, while researching the standard, I am wondering whether empty
>> DEFINE clause is allowed (DEFINE without any variable definition at
>> all). [...] So, it seems a bare DEFINE clause is not allowed.
>> However searching google, it says that the standard allow a bare
>> DEFINE. Maybe it's a hallucination?
>
> That seems right. DEFINE with no definitions is not allowed; the
> parser rejects it syntactically.
>
> On a related note: since the standard treats variables not listed in
> DEFINE as implicitly TRUE, should we allow PATTERN without DEFINE?

ISO/IEC 19075-5 stats that DEFINE is not optional (Table 18 - Row
pattern recognition in windows - syntax summary) So we should not
allow PATTERN without DEFINE.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp