BNF vs EBNF vs ABNF: which to choose?

Question

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?

Breughel

Answer 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!

Sumpter

Relative to 4*DIGIT: the same can be done in EBNF using the same syntax. – Schumann

In addition: IETF uses ABNF. ABNF is way more handy than EBNF. – Sabrina

Answer 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://www.rfc-editor.org/rfc/rfc7405

Varlet

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

Schumann

You could use instaparse.mojombo.com. Selecting abnf in the Option panel on the right bottom corner of the page – Ichinomiya

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

Paiz

Answer 5

• ABNF has been extensively used on defining protocols, such as HTTP, RTSP and email.
  • Being able to specify exact byte values such as %x41-5A can be useful when defining protocols. --mattmight
• EBNF has been used on defining XML, as well as some programming languages such as Python.

Diurnal

Answer 6

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

Kramlich