On Sun, Aug 24, 2014 at 12:07:29AM +0100, Dominik Vogt wrote:
> 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.
I can't say that surprises me. :) But I do stress your own point that
it is invaluable work.
> > 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.
Righty-o. I'll take a look at ABNF. Hopefully it's close to some form
of BNF I've used before.
> 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.
Right---some of the commits to fvwm-workers@ from me have been as a
direct result of my trying to correlate the documentation and the code
itself, since as you rightly point out, the code is so expressive, the
number of permutations of some options isn't documented.
I wonder though what impact this will have? I mean, can we infer a
pathological case and disgregard any "non-standard" interactions of
options if they occur? One immediate example I can think of (which I'll
check) is the 'Resize' command. I know I changed it to support
direction-based pointer warping and can see already I've introduced
problems there with different command combinations. Oops. I'll assess
the impact.
> * 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.
OK. I'm keen to flesh-out the existing commands further; I'll continue
this tomorrow.
> 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".
I agree, 110% with this aim.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
