That may be the right call. It'll be significantly easier to parse
things from C if you only have to check one line and don't need to look
for duplicate keys on other lines.
Absolutely. No duplicate keys, no extension lines; therefore arbitrary-length lines, which are easy to handle in any modern implementation of any language. I'm okay with substructure, though, on the same rules: no duplicate subkeys.
I'm almost sold on that approach. The
only things that worry me are grep, sed and ark which incorporate
duplicate keys by default.
They'll handle duplicate keys, but the SRFI is going to prohibit them (per above) and therefore they aren't going to be a problem.
True - it should be allowed on Zawinski's Law grounds.
What, that -V will expand until it can read mail?
For a long time, GNU hello (which exists basically to demonstrate what a compliant GNU C program looks like) had the -m switch, which searched the colon-separated pathnames in $MAIL and sent the contents of the first such file that existed to standard output. I pointed out a bug which caused it to go into an infinite loop if the first such file didn't exist. I reported the bug, but the -m switch was removed instead. It's not a very useful feature now that so many people's inboxes aren't on their own systems.