Is a BNF grammar for a language acceptable for review as concrete code?

Let's contrast EBNF and Regex.

EBNF is a very narrowly defined class of grammars, suitable to recognize Type-2 Languages. It has the concept of "character-classes" and quantifiers. It also supports arbitrarily named rules. In the vast majority of cases, tools using it support recursing said rules (whether left- or right-recursion is irrelevant).

Regex on the other hand is based off a theoretical CS "Regular Expressions", which are a different representation for Type-3 Chomsky-Grammars. Regex engines generally support character-classes, capturing groups and quantifiers. Quite a few engines support Lookaheads and Lookbehinds (positive as well as negative). This is not true for all engines though.

Regex Engines can be vastly different in what they support. Because a given regex is theoretically independent of its engine, we require the surrounding and calling code for all regex questions. It's impossible to review a Regex alone, because some simplifications simply are not supported by Engines.

Opposed to that, the concept of Lookaheads, Lookbehinds and other "Engine-Dependent" features is not remotely as prevalent in EBNF. While there are some grammar tools out there that support special checks, these special checks are generally not impossible to express in raw EBNF (or in another engine's special checks). That is the difference between EBNF and Regex

EBNF Grammars are meaningfully reviewable in contrast to Regexes, because there's a defined feature set to which EBNF is restricted.

Personally, I don't see how BNF is not a language. Say, wikipedia is not only describing it as a "notation" but also mentions it's a metalanguage.

If we allow questions in sql, then we should allow the questions in BNF because both describe some desired result. In case of SQL it's the data slicing and dicing; in case of BNF it's the interpreters/compilers behavior.

I don't see any reason why not treat BNF as a programming language, especially remembering that there are tools capable of generating at parsers for given grammars. It's declarative. So what? It's "high-order"/"meta-". So what?

The grammars can sometimes be optimized ("refactored" in a sense) just like regular code, therefore the code review is more then valuable. Even though it may be viewed as a design review exercise, technically it's still a code review too.

I agree with @Mast: if the code is concrete; and a particular grammar is complete (e.g. no missing/hypothetical tokens are present); the question should be fine.

Yet, I'd recommend fixing the following part to remove possible interpretation:

// omitted for simplicity
literal_number  : ...
literal_string  : ...
identifier      : ...

Do describe those things for completeness. You can put them into a separate "spoiler" session if it makes your question visually bloated.

P.S. this is just my two cents and I should have kind of a half-vote on that topic because I myself is still very new to CR.SE.

Disclaimer: I have a vested interest in this question.

While answering it I had an uneasy feeling that the question may not be on topic. First, the OP admitted that the results are not expected (OK, could be a problem with the parser). Second - which is most important - the question emanated the feeling of the hypothetical code. I decided to gave the OP a benefit of doubt.

In the wild, questions like this shall be addressed during the design review cycle. We however seem to be very relaxed about code vs design reviews; indeed we suggest alternative designs and implementations quite often.

I don't see the strong guideline. IMHO, we must decide on a case-to-case basis.

• Since we allow regular expressions, I think it's acceptable to allow BNF, EBNF, etc.

  However, unlike with regex, I don't think including another language tag should be a requirement - tagging with regexpython. This is as we only require the language so we know what regex engine the OP is running.

  If the OP however is running a nonstarndard version of *BNF*, then we should require the ability to use the engine. This is as we don't know if it's actually a language, or if there are any quirks with this engine.

• The question however should be off-topic.

  • The code is broken according to the OP. And they have come here for us to fix it for them:

    the parser works perfectly but some problems with the syntax itself are causing undesirable behaviour

  • The question shouldn't be off-topic due to having a nonstandard compiler. As the code looks to be standard EBNF. Despite the OP using a custom engine:

    I have written [...] a simple recursive descent parser.

    However, if the same input to this custom compiler results in nonstandard output then we should close the question until we can verify the code works with the custom compiler.