It seems they were trying really hard to make EBNF NOT look like the grammar it is representing.
> ISO/IEC 14977:1996 represents “one or more” as { symbol }- which means “0 or more symbols, and then subtract the empty set
It's almost as if they were looking for a special syntax to express "1 or more".
Bizarre ... just bizarre.
(5) -> Once you get it you get it.
Every language specification is odd in its own special way. In any case I haven't really seen BNF/EBNF used in the last few years, so this is probably a moot discussion.
e.g. https://github.com/llvm/llvm-project/blob/llvmorg-20.1.5/cla... and https://github.com/python/cpython/blob/v3.13.3/Grammar/pytho...
"ISO" (International Standards Organization), where you have "national member bodies", should absolutely be a thing of the past for programming languages (or for anything related to computing). My country's national body's own homepage has a huge tirade, aiming to "dispel myths", such as the "myth" that "standards should be available free of charge". Meanwhile, lots of std orgs have published computing standards with various degrees of openness already.
ISO is a relic when it comes to computing. (So are other standards bodies that choose to remain proprietary; like those behind PCI, SCSI, ... Computing is ubiquitous and these bodies should be forced open by law, for the public interest.)
unfortunately i think there us some degree of collusion here. it’s easier to get your existing proprietary standards ratified if there are fewer players in the room and the palms that need to be greased are clearly marked
Software oriented standards are certainly cheaper than metallurgy, machining, manufacturing, building construction, environmental, health & safety, and the other big classes of standards however they still have quite a cost.
Historically the ISO standards development process for software standards (like the C or C++ standards) happened only in small part asynchronously and historically required large, extended-duration committee meetings where all the details were hashed out in person. This process only really started to change during COVID but even then it's still a very in-person synch-heavy process and that's not exactly cheap to run.
And with most standards, the FDIS (final draft international standard) revisions are made public. They can be found online even if they can be annoying to dig up. For 99% of cases the FDIS revision is more than sufficient and is identical to the published standard minus a typo or grammar mistake here and there.
As the average SW dev or engineer of course you don't need to fork over the cost for the published standard but any large company will probably purchase a catalog of standards rather than deal with the overhead of dealing with FDIS (and any legal risk from not following the "true" standard).
It is also worth noting that pretty much every university library (and many public non-university libraries) has some contract or service that provides access to copies of the standard to members free of cost.
For the horrible tedious details, see the “Policy for the distribution of ISO publications and the protection of ISO’s copyright” aka ISO POCOSA 2012.
https://github.com/kstenerud/dogma/blob/master/v1/dogma_v1.0...
That, and also I needed a language that could describe binary data.
Anyway, my go-to tire kicking for any such binary file description format is parsing .pdf files, since they are ferociously hard, and include backreferences
I came across this recently while writing an article that references Lua, Go and Python (3.8) syntax. Each of them uses a slightly different form of EBNF.
To make them more easily comparable, I wanted to convert all three to the same format. Looking for something fairly standard (not entirely ad-hoc but also not as formal as ISO/IEC EBNF or RFC 5234 ABNF), I came across Wirth Syntax Notation [0] [1]:
syntax = { production } .
production = identifier "=" expression "." .
expression = term { "|" term } .
term = factor { factor } .
factor = identifier | literal | "(" expression ")" | "[" expression "]" | "{" expression "}" .
literal = "\"" character {character} "\"" .
[0] https://en.wikipedia.org/wiki/Wirth_syntax_notation
https://github.com/egberts/vim-syntax-ebnf
And a EBNF format detector:
https://github.com/egberts/filetype-ebnf-grammars
And a master list of all variants of EBNF:
Here is a list of all variants of EBNFs as well as Vim syntax highlighter for EBNF variants:
https://github.com/egberts/vim-syntax-ebnf
And a EBNF format detector:
https://github.com/egberts/filetype-ebnf-grammars
And a master list of all variants of EBNF:
dwheeler•5h ago
teddyh•5h ago
ggm•4h ago
Commentaries say its different, but the differences might not matter?
ucarion•4h ago
90s_dev•2h ago
arh68•2h ago
Q: what's your ideal way to write Unicode characters clearly? In the W3C/XML spec they'll have stuff like [#x200C-#x200D] but I have no idea what those are, without like a dictionary on hand. Points for specificity, but it doesn't scream "readable".
Your point about standards-not-publicly-available is unfortunately similar to, well, laws. In some areas, "the laws" themselves are not public (!) though perhaps it's a digression better to not get into
pedantically, s/unabiguously/unambiguously/g
alfiedotwtf•1h ago
I’ve never seen PCRE used for grammars and not sure if it would be powerfully enough for all cases, but personally I think it would be pretty cool since I find it easier to read than EBNF and it’s so widely used people can slot a specification right into code and it should just work