Re: Lpeg practices

[steve donovan <steve.j.donovan@...>]

On Tue, Jun 12, 2012 at 11:16 PM, William Ahern
<william@25thandclement.com> wrote:
> Know your grammar first, then write the PEG. Unlike for regexes, I don't
> think there's any viable substitute for spending time grasping the
> conceptual structure of what you're trying to parse.

A good point - by now our brains are pretty much regexp-trained. And
it's natural to try to start explaining PEGs by equivalent regexps,
which may be pedagogically sound but is a 'necessary simplification'
which needs to be later addressed. (Teaching is often about knowing
what to push on the stack for later.)

Once the structure is known, a PEG grammar is relatively simple. And
running it will just give the equivalent of 'no' and 'yes'; the hard
bit is attaching the semantic actions and decent error reporting.
Hence my suggestion to write and test the terminals in isolation,
while the conceptual brain is working on the structure.

For someone from a tradiional lex/yacc grammar background, the mixing
of lexical and syntactical elements can be an obstacle to clarity
initially. Then the discipline is similar, make sure the terminals
handle any lexical details (like the common lpeg.space^0 requirement)
and then the grammar is easier to read.

However, I will freely confess to being but an egg.[1]

steve d.

[1] once did a working C++ parser with Bison; in the process many
kittens were slaughtered and ponies stillborn. The interpreter worked
fine (within limitations) but there must be a better way..