What if we used a slightly different definition of the semantics of “not” - such that 

!keyword, QName, “(“

means “fail if keyword successfully completes and the parser can advance” rather than “fail if keyword matches”?

So, essentially, either we can match a <keyword>, and advance to the next state when we come to a literal “(“ (in which case, the parse fails), or we cannot (in which case, we ignore <keyword> and behave as though we have started trying to match <QName>). 

Would that work?

Thinking about it, I guess you’d either have to backtrack, or run the two matches in parallel, which removes the advantage Stephen was talking about. 

BTW

****************************************************

Dr. Bethan Tovey-Walsh

linguacelta.com

Golygydd | Editor geirfan.cymru

Croeso i chi ysgrifennu ataf yn y Gymraeg


On 20 Jan 2025, at 15:34, John Lumley <john@saxonica.com> wrote:


On 07/01/2025 12:46, Steven Pemberton wrote:
I have informally convinced myself that the NOT proposal by 'alfsb' (https://github.com/invisibleXML/ixml/issues/249#issuecomment-2549656848):

* Is functionally equivalent to the subtraction proposal, but computationally more efficient. (Because with subtraction, both parts are always tried, but with 'not', the second is tried only if the first fails.)
* Can be implemented in all general parsing algorithms.
* Solves the problem without the need of the complication of a lexer stage (which would need a similar mechanism anyway).
* Is pleasantly declarative.

EXAMPLE

identifier: !keyword, [L]+.
keyword: "if"; "then"; "else"; "begin"; "end".

I think we should study it further.

During the last meeting (https://www.w3.org/2025/01/07-ixml-minutes) I said the NOT operator was like the subtraction one I've been using. On further reflection this is NOT the case. 

For example in

functionCall: QName ¬ keyword,-"(", arguments, -")".
keyword: "if" | "return" | ....

would match i(...) or iff(..) but not if(...).

But using the NOT operator:

functionCall: !keyword, QName,-"(", arguments, -")".
keyword: "if" | "return" | ....

would succeed for i(...) and fail for if(...), as expected, but would also fail for iff(...) which is not the intent as the leading two characters match keyword and cause the rest of the production to fail.

 The key to the subtraction is that it fails if the RH term completes over exactly the same characters as the LH term, but succeeds in all other cases where the LH term matches.


--
John Lumley MA PhD CEng FIEE
john@saxonica.com