Pegged, From EBNF to PEG

[Philippe Sigaud]

On Tue, Mar 13, 2012 at 17:17, Dmitry Olshansky <dmitry.olsh at gmail.com> wrote:

> PEG defines order of alternatives, that is pretty much like a top-down
> recursive descent parser would parse it. Alternatives are tried from left to
> right, if first one fails, it tries next and so on.

Yes.

> In an example I give B is always picked first and so C is never ever looked
> at.

That's one of the caveats on PEG. That and greedy operators.

'a*a' never succeeds because 'a*' consumes all the available a's.


>> Literal <- ("'" .+ "'") / ('"' .+ '"')
>>
> This needs escaping. Plain '.+' in pattern asks for trouble 99% of time.

This is an example were PEG would munch anything till the end, and
fail (since """ is not found in an empty string).
The standard PEG way to do that is

(!EndMarker .)+ EndMarker

It's a common enough pattern I tend to define a parameterized rule for that:

Until(Expr) <- (!Expr .)* Expr


Gotta love parametrized rules! 15' to code, a neverending stream of joy.


> In fact grammars are usually devised the other way around, e.g.
> Start:
>  Program -> ...
> Ehm... what the whole program is exactly ? Ok, let it be Declaration* for
> now. What kind of declarations do we have? ... and so on. Latter grammars
> get tweaked and extended numerous times.
>
> At any rate production order has no effect on the grammar, it's still the
> same. The only thing of importance is what non-terminal considered final (or
> start if you are LL-centric).

Yes. The PEG standard seem to be that the first rule is the start
(root) rule. Pegged let you decide which rule you use for a start. The
rest is automatic.
I might change that.