[antlr-interest] Modifying tree based on semantic content
David Jameson
dhjdhj at gmail.com
Fri May 15 06:15:47 PDT 2009
I hate to bother you with more on this but I ran into difficulty when
I tried to translate the simple question/response into my real grammar.
My actual rule in my grammar is below --- I added two rewrite
predicates, the idea being that if the type of LHS is a string, then
my tree will have an extra token in it, making the tree parser grammar
trivial.
However, when I try to generate the grammar from this, I get the error
expecting RPAREN, found '->'
and the row/col value indicates the beginning of the second predicate
I'm probably missing something stupid here but I can't see it.
D
--------------------------------------
expression returns [TAttributeType type]
:
optionalSign
lhs = simpleExpression
{
$type = $lhs.type;
}
(
(comparisonOperator^ rhs = simpleExpression)
{
$type =
TErrorHandling.Compatible($comparisonOperator.tree.token,
$comparisonOperator.token, $lhs.type, $rhs.type);
} -> { isString($lhs.tree) } ^(comparisonOperator
STRINGCOMPARE lhs rhs)
-> ^(comparisonOperator lhs rhs)
)*
;
comparisonOperator returns [int token]
: EQ { $token = EQ; }
| NE { $token = NE; }
| LT { $token = LT; }
| LE { $token = LE; }
| GT { $token = GT; }
| GE { $token = GE; }
On May 15, 2009, at 7:57 AM, Steve Ebersole wrote:
> On Fri, 2009-05-15 at 07:34 -0400, David Jameson wrote:
>> I was not aware of this kind of construction. Thank you for bringing
>> it to my attention. Where is there an article that specifically
>> discusses this mechanism? I couldn't find it in my ANTLR book nor
>> through (a few) google searches?
>>
>> In other words, what exactly is "areStrings(...)" --- is it just a
>> function that returns boolean? I'm assuming that the syntax here
>> implies that you can have a sequence of these
>> -> { .... } TREE
>> lines and that ANTRL looks for the first expression in braces that is
>> "true"
> Here specifically I would assume that areStrings(...) would be a
> grammar
> member function so that the types of the 'a' and 'b' expressions could
> be determined. But in general yes, the fragment inside {} just
> needs to
> evaluate to a boolean value. I believe these are called rewrite
> predicates(?). And yes, just like regular predicates you can list
> multiples and the first match will "win".
>
>> Is that correct?
>>
>> D
>>
>>
>> On May 15, 2009, at 7:26 AM, Steve Ebersole wrote:
>>
>>> someRule
>>> : a PLUS b
>>> -> { areStrings($a.tree,$b.tree) } ^(CONCATENATE a b)
>>> -> ^(PLUS a b)
>>>
>>> On Thu, 2009-05-14 at 23:38 -0400, David Jameson wrote:
>>>> Is there any way to control the built-in tree generation (from an
>>>> initial parse phase) based on semantics of what is being parsed?
>>>>
>>>> As a simple example, if I see the expression
>>>> a + b
>>>>
>>>> then I want to produce
>>>> (PLUS a b)
>>>> or
>>>> (CONCATENATE a b)
>>>>
>>>> depending on whether a and b are numeric or string.
>>>>
>>>>
>>>> How can I do this with rewrite rules (for example)? Or do I
>>>> have to
>>>> construct my own trees?
>>>>
>>>>
>>>> Thanks,
>>>> D
>>>>
>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>>> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>>> --
>>> Steve Ebersole <steve at hibernate.org>
>>> Hibernate.org
>>>
>>
>>
>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> --
> Steve Ebersole <steve at hibernate.org>
> Hibernate.org
>
More information about the antlr-interest
mailing list