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

Syntax for a simple scripting language is a question asking for a review of a grammar of a C-like language. The grammar specification isn't an input for any specific parser generator tool:

I wrote this grammar myself just as a reference while working on the interpreter, as I wrote the parser myself by hand, not using yacc/antlr or any generators. So it might be using the wrong symbols or not be a recognisable structure, for which I can only apologise and hope the meaning is still clear — JamesMac

Should Extended Backus-Naur Form be considered a suitable language for Code Review? Otherwise, the question seems to violate the "no pseudocode" rule.

• We usually except any language of which the rules are written down. If EBNF is concrete enough, it could work. However, I'm not sure that's the case here. – Mast Jan 19 '18 at 20:48
• In either case, I'm wondering if we might need a new central tag for these "new" languages or if we should just allow tags like grammar to suffice for them only. – Jamal Jan 20 '18 at 1:31
• @Jamal Sounds like a new meta question, but I'd say every language needs a language tag. – Mast Jan 20 '18 at 8:32
• If it's machine-readable (and the asker has actually tested it, with examples of correctly accepted and rejected inputs), then it's a language. If it's intended only for humans, then it's not a (programming) language. – Toby Speight Jan 22 '18 at 9:54

### 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 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.

• Are you pro or con considering EBNF a language by itself? I'm having some trouble parsing your answer. – Mast Jan 20 '18 at 22:04
• mostly pro, Not a hill I'm ready to die on. – Vogel612 Jan 21 '18 at 0:36

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 , 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 . 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.