- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Mon, 15 Apr 2024 15:37:20 +0000
- To: ixml <public-ixml@w3.org>
https://github.com/invisibleXML/ixml/blob/master/misc/ebnf-to-bnf.md
General comments:
I appreciate the approach of this article, though it does reflect a
different idea to mine of what is behind rewriting rules.
Parsing algorithms don't need to deal with EBNF extensions, because all the
extensions are only syntactic differences intended to make life easier for
the author and reader, and all grammars written in EBNF can be rewritten,
as this article shows, to equivalent BNF forms.
Accordingly, I consider the rewriting as equivalent to code generation, and
is indeed how I treat it in my implementation. So parse algorithms don't
need to deal with EBNF constructs for the same reason that machine opcodes
don't have to deal with WHILE loops. The parse algorithms remain simple,
while the grammar is written in a higher-level language.
So I consider the rewrite rules purely as an implementation detail.
However, the real point of this article I think is in the conclusion, that
some rewrites are faster than others, and implementers should experiment.
Two points that make the article harder to read:
1) The "|" separator for alternatives was an addition made to BNF from
Chomsky's notation, and has by definition no inherent ordering. Alternative
rewrites such as A: B | C. and A: C | B. confused me since they are
equivalent. If there is a reason to give them, it should be explained, and
it would be far better right at the beginning to say that there is such an
equivalence, which can be applied everywhere. This would make a lot of the
examples easier to read because there would be no need for this repetition.
2) There is a implication (for instance in (4a) that bracketing is BNF
("The following BNF grammar ... S = ('a' | -S), 'b'.) However, bracketing
is EBNF, and later examples of how to deal with it are given, so any
rewrites using bracketing are only EBNF -> EBNF, and this should be made
clearer in the text.
Detailed Comments
"textual insertions" This is an odd thing, because ixml grammars specify
both input and output, and I don't consider insertions, or marks for that
matter, as part of the grammar, but part of the output specification.
Therefore I don't think of them as extensions to EBNF in the sense
suggested here. However, I do agree that repetition with separators are an
addition to EBNF.
"Nested choices". I think this is what I mean by bracketing, but in any
case an example would help here.
(O1a)(O1b) This is an example of giving the same expansion twice as if |
isn't commutative.
(PP2) The sentence is missing something.
Steven
Received on Monday, 15 April 2024 15:37:25 UTC