BNF vs EBNF vs ABNF: which to choose?

问题

I want to come up with a language syntax. I have read a bit about these three, and can't really see anything that one can do that another can't. Is there any reason to use one over another? Or is it just a matter of preference?

回答1:

You have to think about EBNF and ABNF as extensions that help you just to be more concise and expressive while developing your grammars.

For example think about an optional non-terminal symbol, in a BNF grammar you would define it by using intermediate symbols like:

A        ::= OPTIONAL OTHER
OPTIONAL ::= opt_part | epsilon

while with EBNF you can do it directly using optional syntax:

A ::= [opt_part] OTHER

Then since there's no way to express precedence in a BNF you have to use always intermediate symbols also for nested choices:

BNF
A ::= B C
B ::= a | b | c

EBNF
A ::= (a | b | c) C

This is true for many syntax issues that are allowed in an EBNF or ABNF grammar, thanks to syntactic sugar but not with a normal BNF. ABNF extends EBNF, allowing you to do more complicated things, like specifying how many occurrence of a symbol can be found together (i.e. 4*DIGIT)

So choosing an ABNF or an EBNF as language of choice for your grammar will make your work easier, since you will be more expressive without filling you grammar with useless symbols that will be generated anyway by your parser generator, but you won't care about them!

回答2:

According to Wikipedia, ABNF's double quoted string literals are case-insensitive, and case-sensitive matches must be defined as numeric ASCII values. I consider that a disadvantage.

Literal text is specified through the use of a string enclosed in quotation marks ("). These strings are case-insensitive and the character set used is (US-)ASCII. Therefore the string “abc” will match “abc”, “Abc”, “aBc”, “abC”, “ABc”, “AbC”, “aBC”, and “ABC”. For a case-sensitive match the explicit characters must be defined: to match “aBc” the definition will be %d97.66.99.

https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form#Terminal_values

However, RFC 7405 seems to add case-sensitive string literals to ABNF.

https://tools.ietf.org/html/rfc7405

回答3:

The EBNF is the extended/newer version of BNF, so the problem becomes simpler: EBNF vs ABNF. I'm not an expert, but think that it should depend on a language, whose syntax you want to define. Also there are some visualizers for EBNF (http://www.google.co.il/search?sourceid=chrome&ie=UTF-8&q=Ebnf-Visualizer), but didn't see any for ABNF,

回答4:

A reasonable choice would suggest to go with EBNF, for the reason it's an ISO standard: ISO/IEC 14977 : 1996(E) [pdf]. As an example, it's used for the OMG's UML Human-Usable Textual Notation.

回答5:

You can achieve what you want by using any of them, but each one is concise and effective in representing your language depending on what are the features that your language consists of.

I have read BNF, EBNF and ABNF from wikipedia and it has described some differences and why EBNF and ABNF came into picture based on BNF

来源：https://stackoverflow.com/questions/2575044/bnf-vs-ebnf-vs-abnf-which-to-choose