- 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