[antlr-interest] String Templates and return values

Andreas Stefik stefika at gmail.com
Wed Mar 16 07:37:46 PDT 2011


Thanks Michael, this helps. I'll give it a try and see what happens.

Stefik

On Tue, Mar 15, 2011 at 8:54 PM, Michael Bedward
<michael.bedward at gmail.com> wrote:
> Oops...
>
> The tree walker action for expressionList should be:
> { $list.add(e); }
>
> Rather than
> { $list.add($e); }
>
> Sorry about that.
>
> Michael
>
> On 16 March 2011 12:51, Michael Bedward <michael.bedward at gmail.com> wrote:
>> Hi Andreas,
>>
>> The problem is that when using template output the generated code for
>> your ArrayList will look like this...
>>
>> list_exprs.add(exprs.getTemplate());
>>
>> ie. it is a list of *templates* not a list of rule return scopes.
>>
>> One way to get around this is to do something like the following...
>>
>> In your token parser grammar...
>>
>> funcCall : ID '(' expressionList ')' -> ^(FUNC_CALL ID expressionList) ;
>>
>> expressionList : (expression (',' expression)* )? -> ^(EXPR_LIST expression*);
>>
>> Then in your tree walker grammer...
>>
>> expressionList returns [List list]
>> @init { $list = new ArrayList(); }
>>        : ^(EXPR_LIST ( e = expression {$list.add($e);} )
>>        ;
>>
>> funcCall : ^(FUNC_CALL ID expressionList)
>>             {
>>                 for (Object o : $expressionList.list) {
>>                     // do stuff
>>                 }
>>             }
>>             ;
>>
>> Hope this helps.
>> Michael
>>
>>
>> On 16 March 2011 08:15, Andreas Stefik <stefika at gmail.com> wrote:
>>> Hello all,
>>>
>>> My team is changing over our existing grammars from
>>> Parser->TreeWalker, to adding a new phase where we are outputting text
>>> from String templates. We have made some test grammars, which work
>>> fine, generating some output, but are having some difficulty
>>> integrating templates into our real system. Specifically, we started
>>> out doing the simplest thing, putting output = template; into the
>>> options. After changing around some of our grammar to account for
>>> different return types from outputting templates, we ran into one
>>> grammar rule that we haven't quite figured out how to fix:
>>>
>>> ^(FUNCTION_CALL qualified_name(COLON ID)? LEFT_PAREN ({temp++;}exprs
>>> += expression (COMMA exprs += expression)*)? RIGHT_PAREN)
>>>
>>> Inside the semantic action for this rule is the following:
>>>
>>> if($exprs != null) {
>>>                        for(Object o : $exprs) {
>>>                                expression_return ex = (expression_return)o;
>>>                                types.add(ex.eval.getType());
>>>                                argumentTypes.add(ex.eval.getType());
>>>                                steps.add(ex.step);
>>>                                values.add(ex.eval);
>>>                                registers.add(ex.eval.getRegister());
>>>                        }
>>>                }
>>>
>>> Basically, we are adding expressions into an ArrayList (exprs +=
>>> expression), which we then crawl through to grab details for the
>>> parameters. However, when we comment out output=template; this code
>>> works just fine, but when we leave it in, the array list is populated
>>> with null values. I don't quite understand what is going on here. For
>>> example, the code generated for the expression return looks about the
>>> same:
>>>
>>> //templating on
>>> public static class expression_return extends TreeRuleReturnScope {
>>>        public ExpressionValue eval;
>>>        public ExecutionStep step;
>>>        public StringTemplate st;
>>>        public Object getTemplate() { return st; }
>>>        public String toString() { return st==null?null:st.toString(); }
>>>    };
>>>
>>> as opposed to
>>>
>>> //templating off
>>> public static class expression_return extends TreeRuleReturnScope {
>>>        public ExpressionValue eval;
>>>        public ExecutionStep step;
>>>    };
>>>
>>> I assume that, perhaps, there is some other way should be doing this. Any clues?
>>>
>>> Stefik
>>>
>>> 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