Description
Hi.
it seems combining the start anchor with a (minmax) quantifier causes the interpreter to miss what I would consider matches in cases where @ is put with inner rule elements like so:
(W @W W)[2,2]; // or (W @W W W)[3,4]; // or (W W @W W)[2,3];
On the other hand,
(W W W w)[2,2];
would match passages as expected. I suspect this is caused by the changed matching order within the composed rule element when it is applied multiple times.
Minimal Example:
Script:
(W @W W W)[2,2]{-> T1}; (W W @W W)[2,2]{-> T2};
Text:
omega alpha beta gamma omega alpha beta gamma omega alpha
Expected matches:
- T1, T2: omega alpha beta gamma omega alpha beta gamma
- T1, T2: alpha beta gamma omega alpha beta gamma omega
- T1, T2: beta gamma omega alpha beta gamma omega alpha
Actual matches:
- T2: beta gamma omega alpha beta gamma omega alpha
Or, since I could not find anything on the intended behaviour in such cases in the Guide, the broader question is how the interpreter is supposed to handle @ in a composed rule element that is also quantified. E.g. is it supposed to ignore the anchor from the second application (on the same match) onwards?
Best, Michael