The CMake Language BNF appears ambiguous

Development
1

I just started looking through the CMake Language and associated BNF. It might be useful to see if your language is suitable for a LALR(1) parser generator (bison) or a LL(1) parser generator (ANTLR) after separating lexemes from BNF. A few comments which I’m confused over:

  1. There is no description of the BNF meta language, for example, <match…>, ?, ‘*’ , ‘+’. I assume the following definitions
    • ?: 0 or 1 instance.
    • *: 0 or more instances.
    • +: 1 or more instances.
    • <match ..> defines some lexical characteristics but is itself ambiguous, that is there are some inconsistencies in the definition.
  2. The BNF describing spaces in statements seems difficult to understand. Either a simple statement that “where one space is allowed, many can be used” with either BNF or verbiage to support the allowable or required language elements where this applies to. The use of space* is confusing.
  3. Legal CMakeList.txt files:
    • An empty file.
    • A file consisting of an indefinite number or either newlines and/or comments.
    • A file with a mixture of the above and expressions.
  4. The following syntax appears ambiguous:
    arguments ::= argument? separated_arguments*
    separated_arguments ::= separation+ argument? |
    separation* '(' arguments ')'
    The reason is that argument? and separated_arguments* appear to conflict for a single argument. The BNF reduction is ambiguous, it is not an LR(1) language.
    Using BNF for a LALR grammer in its non-expanded form (w/o ‘*’, ‘?’, ‘+’) we get:
    arguments := arguments space argument | argument |
    argument := unquoted string | quoted string | Lua thing
  5. There is a Lua example but no reason given for why it is needed. To my humble eyes a quoted string, “string …”, with or without newlines would serve the same purpose.
  6. Separation of lexemes is not done. Identification of lexemes in BNF is firstly a mistake, and leads to things like <match …>, I assume match is meant to define lexemes.
  7. is something like the below legal in your BNF?
    command( argument1 # comment
    argument2 # comment
    )

An excellent and pragmatic source for actual structure of language descriptions and the impact of separating lexemes from BNF is the book C: A Language Reference Manual by Harbison and Steele. I have found edition 2/3 to be quite good with following editions tending to academic representations. In this book you can see a clear separation of lexemes from BNF, and can look at its consequences.

The C: A Language Reference Manual, with suitable alterations, exactly matches what you are trying to achieve in your CMake Language description.

The BNF seems more confusing than it should be.