On 14.03.2012 2:49, Philippe Sigaud wrote:
On Tue, Mar 13, 2012 at 17:17, Dmitry Olshansky<[email protected]> 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.
Hey, wait, I thought there has to be backtrack here, i.e. when second
'a' finally fails?
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.
Nice!
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.
--
Dmitry Olshansky
