- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Thu, 6 Jan 2022 08:39:06 -0700
- To: Tomos Hillman <yamahito@gmail.com>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Norm Tovey-Walsh <norm@saxonica.com>, ixml <public-ixml@w3.org>
> On 6,Jan2022, at 3:40 AM, Tomos Hillman <yamahito@gmail.com> wrote: > > I'm not sure I understand approach B, or how it avoids ambiguity within the non-terminal definition: there may be only one parse tree, but surely the fact that it contains a choice means that it is itself ambiguous in some way? Define “ambiguity”. > > I also seem to recall (unreliably) that implementations are not bound to return all possible ambiguous results, only to note that there is an ambiguity: do we actually have a situation where different parsers would disagree about whether the parse was ambiguous, without having to agree on what exactly the nature of that ambiguity is? Yes, we do. On the empty string, parsed against S = ‘a’*; ‘b’*. Steven’s parser and mine produce different results. His parser claims the string is ambiguous, because it implicitly defines ambiguity in one way (my conjecture: in terms of the ambiguity of the sentence against the underlying BNF grammar), and mine claims the string is unambiguous because it implicitly defines ambiguity a different way (number of raw parse trees, where a raw parse tree has nonterminals at the internal nodes, terminal symbols at preterminal nodes, and characters at the leaves). > Or do we have to say that it is implementation dependent on whether or not ambiguities are detected? What does “have to” mean here? Michael
Received on Thursday, 6 January 2022 15:39:25 UTC