It has its own renderer, so you can take your code and render it for insertion into a paper. It uses Felleisen-style reduction syntax, which is useful because it exposes the current continuation of a program explicitly.
I can't help but agree with Temporal's comment in that thread: it reads like a practical joke. Both.the extensive pointless histories, presenting unreadable grammars, then BNF variants, then dismissing the BNF variants for a variant over the unreadable grammars.
At the same time I don't think it was a joke. So many CS papers are infested with excessive use of formalisms that makes the papers less accessible for no gain.
It's at times like this that being an engineer instead of a computer scientist becomes an issue. I feel exhausted from reading it and I know I'll need to make notes to properly digest what they are talking about - I was exposed only to a subset of the many notations used and it'll take some work to correlate them.
In my Informatics Engineering degree, this kind of stuff was part of compiler design and programming languages lectures, and on my time they weren't optional.
So it is more a matter of what an university decides to make available than being a CS.
BNF and railroad diagrams contain the exact same info though... one BNF rule translates 1:1 to one railroad segment. I wrote a program[1] to convert BNF directly to railroad diagrams, and there are many others like it.
And not even just parsing as most people interpret it. Most practical custom data types can be expressed using a BNF grammar or something close to it (formally in the language, or informally by understanding the language and its representations). The structure of the code falls out of that in many situations (though certainly not all) as it determines what can be done at any particular point.
Oh, how I wish more protocols in particular had been defined in something like BNF, and asked themselves for very good reasons why they insist on something that makes that hard.
So many abominations of data structure and protocol designs have come out of people not bothering to write down a grammar of any type until after they'd already come up with something broken.
In fact, I'm hacking on a Ruby implementation where just operator overloading and some simple methods is sufficient to get a BNF variant written as code to return a structure encoding parser combinators on execution.
(There's nothing new about that, it's been done before, other than perhaps the sick and twisted levels of abuse of the Ruby syntax I'm toying with thanks to a newish feature (refinements) to make it look closer to plain BNF).
And if course, automatically "compiling" bnf into parser combinators is easy.
The only limit I've ever reached with BNF is that you cannot express permutations of given set of rules, you really have to write every possibility literally.
It takes fairly small extensions to BNF, though. When I write parser generators (sentences I didn't think I'd write, but it's been quite a few), there are a few things I'd often add extra constructs for. One being lists (term = value ("," term)? or variants occur often enough that introducing a list syntax that reduces pointless recursion is helpful), and other being patterns, e.g. when defining operator precedence, which I'm guessing is what you're thinking of?
Being able to recursively generate a rule-set where each level takes the head of a list is very useful.
I interpreted (maybe misinterpreted) that as lamenting having to write out priorities of operators, as that's the most common set of rules in BNF where you end up with near identical permutations. E.g:
term = term2 [op1 term]
term2 = term3 [op2 term2]
... and so on for every precedence level. A lot of BNF grammars for simpler languages are dominated by rules following that pattern.
