Working through your example below, I *think* the PEG is as follows:
rp-expression <- rp-expression_
rp-expression_ <- rp-expression-operand ( rp-expression OPERATOR )*
rp-expression-operand <- OPERAND
; to complete my pretend example
OPERATOR <- ,"+" / ,"-" / ,"*"
OPERAND <- [[:digit:]]
But those top three productions simplify to:
rp-expression <- OPERAND ( rp-expression OPERATOR )*
And running that through the example given in another e-mail, I generate
this parse tree:
(#\5 ((#\4 "*") ((#\2 ((#\1 "-"))) "+")))
I think I'm still confused, I really appreciate your continuing to
help me. I missed something simple?
-Alan
On Wed, Apr 13, 2011 at 11:22:39AM -0700, Terence Parr wrote:
> Hi Alan, sorry for the confusion. ANTLR accept rule parameters and return
> values that it injects into the generated code so
>
> r[int i] returns [int x] : ... r[elist] ... ;
>
> yield something like
>
> int r(int i) { ... r(elist); ... }
>
> In this case, we don't need any of the precedence operation stuff; stripping
> by hand, we get
>
> rpexpression : rpexpression_ ;
> rpexpression_
> : rpexpression_primary
> ( ( rpexpression OPERATOR ) )*
> ;
> rpexpression_primary
> : OPERAND
> ;
>
> Ter
> On Apr 13, 2011, at 10:54 AM, Alan Post wrote:
>
> > 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
>
>
> _______________________________________________
> 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
