I don't quite understand your syntax, can you pull me through it?
Is see that the rpexpression production has been broken int an
rpexpression, rpexpression_, and prexpression_primary, but I'm
confused by the [0] and [int _p] tags. They seem like number of
matches on that production, but I haven't quite worked out how
to describe that without doing so circularly.
Will you pull me through?
-Alan
On Wed, Apr 13, 2011 at 10:44:14AM -0700, Terence Parr wrote:
> Hi Robin,
>
> Well, my little pattern matching thing would see that as a "nonstandard"
> operator (not binary or unary etc.) and consider it a suffix operator because
> it begins with immediate left recursion. It may not be pretty, but here is
> what I get from
>
> rpexpression
> : rpexpression rpexpression OPERATOR
> | OPERAND
> ;
>
> becomes
>
> rpexpression : rpexpression_[0] ;
> rpexpression_[int _p]
> : rpexpression_primary
> ( ( {_p <= 3}?=> rpexpression OPERATOR ) )*
> ;
> rpexpression_primary
> : OPERAND
> ;
>
> Does not look correct? I have to jump off and prepare for class :) If not, I
> better add a note to look into it.
> Ter
> On Apr 13, 2011, at 10:37 AM, Robin Lee Powell wrote:
>
> > On Wed, Apr 13, 2011 at 10:26:14AM -0700, Terence Parr wrote:
> >> On Apr 12, 2011, at 12:31 PM, Laurence Tratt wrote:
> >>> On Tue, Apr 12, 2011 at 08:47:42AM -0700, Terence Parr wrote:
> >>>
> >>> Dear Terence,
> >>>
> >>>> Only limitation is immediate-left-recur handled only. In my
> >>>> experience, that's good enough :) No point in some complicated
> >>>> algorithm when this covers any grammar I'd care about.
> >>>
> >>> A quick question: is any type of direct left recursion handled?
> >>> I'm probably being an idiot here (it's my normal mode), but your
> >>> wiki post suggests that this relies on the grammar being built
> >>> in an "expression" sort-of way, but the above post suggested
> >>> there might be a bit more flexibility?
> >>
> >> Hi. Yep, in the end, it was straightforward to convert any
> >> immediate left recursion
> >
> > People keep saying that, but I can't seem to figure it out. I
> > especially can't see any way to deal with left recursion that
> > doesn't totally break the meaningfulness of the resulting parse
> > tree.
> >
> > Here's the bane of my PEG existence, from the Lojban grammar; it's a
> > very simple two-argument-only RPN calculator:
> >
> > rp-expression <- rp-expression rp-expression operator / operand
> >
> > I can't see any way to fix that that leaves the operators associated
> > with their argumenst properly.
> >
> > I'd love some help, if people have time.
> >
> > -Robin
>
>
> _______________________________________________
> PEG mailing list
> PEG@lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/peg
--
.i ma'a lo bradi ku penmi gi'e du
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
