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
