On 5/15/25 9:39 PM, Carsten Bormann wrote: > On 14. May 2025, at 17:41, Marc Petit-Huguenin <[email protected]> > wrote: >> >> https://datatracker.ietf.org/doc/draft-rivest-sexp/ is a good example of a >> language whose ABNF cannot be normative (that's because the s-exp variant >> described in it is non-context free). > > I think you are saying that the ABNF doesn’t fully describe the language. > I don’t know why this means it can’t be normative — it just describes a > superset, and the remaining details can then be supplied in English (rule > “verbatim” in 7.1, I think).
Yes, but also the quoted-string, hexadecimal, and base-64 rules, when they start with a number. > > This is strictly better than describing the whole language in English (even > though it loses much of the advantage of ABNF, namely to be processable by > common tools). In this particular case, writing a parser was particularly difficult because parsing libraries are designed to work with context free languages. Here I had to modify the parsing library to finally be able to use it for that variant of s-exp. But there was an additional difficulty, which is that a single whitespace is mandatory in some specific cases. I sorted out the rules when I did the formalization, but at the end an ABNF that would strictly follow these rules would have been really confusing. Instead, we crafted the first paragraph of section 5 which expresses the rules more concisely. Because there was anyway no possibility in the first place to automatically derive a parser from the ABNF, I think that not carrying that baggage in the ABNF was the right choice. An additional reason why I think that English sentences are better than ABNF or any other formalism as the normative part of a standard track RFC: most people understand what an English sentence means, and there are plenty of safeguards along the standardization process to make sure that they are correct. This is not, in my experience, the case with formal languages (or examples for that matter, my other pet peeve), and verification tools do not help much past the syntax. Everything I wrote at the IETF these last 10 years was about solving these two issues, so I am not going to repeat that here. -- Marc Petit-Huguenin Email: [email protected] Blog: https://medium.com/@petithug Profile: https://www.linkedin.com/in/petithug
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
