Re: The semantics of the disambiguation constructs

On 03/03/2026 13:00, Steven Pemberton wrote:
> For Earley for instance:
>
> A: !B, C.
>
> If B succeeds then A fails. If B fails then C is parsed from the point 
> in the input where B started.
>
> In the form
>
> A: C!B.
>
> C and B can be parsed in parallel (in the same way that alternatives 
> of a rule are parsed in parallel), and if C succeeds and B fails, the 
> whole construct succeeds, and parsing continues from where C left off, 
> otherwise the whole construct fails.

I think these two cases are not the same and have different though 
related semantics.

If I recast my  'subtraction' use case example as:

  FunctionCall: FunctionName, -"("...
  FunctionName: !ReservedNames, NCName.
ReservedNames: "item";"type";"element"...

with the semantics you imply for the not, then

    elem()

would succeed, but

    element()

would fail, as anticipated. However

    elementary()

would now fail erroneously with respect to the original requirement, as 
ReservedName would succeed at the seventh character and hence 
FunctionName would therefore fail.

As you imply,

        A: !B, C.

has B as a non-consuming test, but in

        A: C!B

B is a consuming-in-parallel test with C


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