On Sat, Aug 23, 2014 at 05:27:35PM +0100, Thomas Adam wrote: > Right. I've spent all day today going through each command listed and > adding the *bare minimum* EBNF notation to them. While I don't have a > lot to show for it, I've more or less done every single command we have, > hand-waiving over the more interesting details. For example, I've not > listed every single style option available.
Good work, Thomas. It's a bit sobering though that we've already spent so much time on it and are nowhere near a form of notation that would allow parsing anything automatically. > Note that the EBNF isn't strictly correct for all grammar types---that > is, I can't use this to build a parser or to generate rail-road > diagrams. If we really do want that, I can improve the syntax to be > more compliant. I've just pushed a commit that cleans up the notation a bit and does a couple of steps in the direction of a real *bnf. I've also converted what we have to abnf (rfc5243) which is more expressive than ebnf. There are several pitfalls to be aware of: * For some commands, the documentation is ambiguous or wrong. Sometimes there are so many options that they interfere with one another, and sometimes the syntax description might allow some combination of options that is actually not allowed. * Many commands ignore the reset of the command line once they are happy with what they've already parsed. > Please take a look---we're not quite there yet, but hopefully I've given > this a heaftier shove in the right direction. Looks good to me, but I fear that we've only done 5% of the work. Next week I'll have more time to help. Maybe I can try to write down the general parsing algorithm in abnf. The direction in which we're heading is right; whatever our ambitions for the new syntax will be, it will help to have everything written down precisely. Eventually we'll have it in lex+yacc format and generating a new parser to experiment with just means running "make". Ciao Dominik ^_^ ^_^ -- Dominik Vogt
