[antlr-interest] Are token aliases possible?

Christian chwchw at gmx.de
Sat Oct 29 04:40:34 PDT 2011


Could you please give an example for your approach?

Am 28.10.2011 19:35, schrieb Jim Idle:
> Get a reference to the token and just set the type property.
>
> Jim
>
>> -----Original Message-----
>> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>> bounces at antlr.org] On Behalf Of Christian
>> Sent: Friday, October 28, 2011 4:46 AM
>> To: antlr-interest at antlr.org
>> Subject: Re: [antlr-interest] Are token aliases possible?
>>
>> Yes, I know that one can use rewrite rules. Thank you anyway. In some
>> cases however, I do not want to repeat the rules following the CLASS
>> token and write an arrow etc. In such cases, it is shorter to just
>> replace the CLASS by CLASS_DECL and add a few operators instead of a
>> rewrite rule.
>>
>> As an example, I want to transform the following rule:
>>
>> class_declaration
>>   : CLASS  type_or_generic   class_base?
>> type_parameter_constraints_clauses?   class_body   ';'?
>>
>> into
>>
>> class_declaration
>>   : CLASS_DECL  type_or_generic   class_base?
>> type_parameter_constraints_clauses?   class_body   ';'!?
>>
>> versus
>>
>> class_declaration
>>   : CLASS  type_or_generic   class_base?
>> type_parameter_constraints_clauses?   class_body   ';'?
>>       -> ^(CLASS_DECL type_or_generic class_base?
>> type_parameter_constraints_clauses? class_body)
>>     ;
>>
>> I think everyone, especially me, would prefer the first solution.
>>
>> Am 28.10.2011 13:34, schrieb Sam Barnett-Cormack:
>>> I don't know for sure, buut my immediate thought is that it isn't
>>> likely to be possible (as tokens are generated without reference to
>>> parse context, and must be unambiguous except where code manually
>>> deals with the ambiguity). You could however create it as a dummy
>>> token name, and rewrite to it in the parser, such that the AST
>>> generated has a 'virtual' CLASS_DECL token generated from the 'real'
>>> CLASS token. Pretty sure there are examples of this in the wiki.
>>>
>>> On 28/10/2011 12:27, Christian wrote:
>>>> CLASS is only the token name. However, CLASS_DECL represents the
>>>> semantics of what was parsed. It allows to be more consequent when
>>>> analyzing the generated AST by names like CLASS_DECL, METHOD_DECL,
>>>> FIELD_DECL etc.
>>>>
>>>> Example:
>>>>
>>>> switch (node.getType()) {
>>>>     case CsRewriteRulesParser.NAMESPACE_DECL:
>>>>        // TODO
>>>>        break;
>>>>     case CsRewriteRulesParser.METHOD_DECL:
>>>>        // TODO
>>>>        break;
>>>>     case CsRewriteRulesParser.CLASS_DECL:
>>>>        // TODO
>>>>        break;
>>>> }
>>>>
>>>> It would be just another name for the integer constant CLASS.
>>>>
>>>> Am 28.10.2011 13:19, schrieb Sam Barnett-Cormack:
>>>>> I think the immediate answer is, "why?"
>>>>>
>>>>> On 28/10/2011 09:02, Christian wrote:
>>>>>> Hi community,
>>>>>>
>>>>>> if there is a real token, say
>>>>>>       CLASS : 'class';
>>>>>> can a define an alias, say
>>>>>>       CLASS_DECL = CLASS
>>>>>> in some way?
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>>
>>>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>>>>> Unsubscribe:
>>>>>> http://www.antlr.org/mailman/options/antlr-interest/your-email-
>> addr
>>>>>> ess
>>>>
>>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>>>> Unsubscribe:
>>>> http://www.antlr.org/mailman/options/antlr-interest/your-email-
>> addres
>>>> s
>>
>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
>> email-address
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>



More information about the antlr-interest mailing list