[antlr-interest] Re: Tree transformation
Arnar Birgisson
arnarb at oddi.is
Sun Nov 16 14:24:27 PST 2003
Hi there,
I tried putting # in front of list, which made it worse. Before, only
the first level of the subtree wasn't being processed, after putting #
in front of the label name, it seems that the whole subtree is not
transformed. The result is just as if I copied the input-tree as-is.
Arnar
> -----Original Message-----
> From: lgcraymer [mailto:lgc at mail1.jpl.nasa.gov]
> Sent: 16. nóvember 2003 20:27
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: Tree transformation
>
>
> Arnar--
>
> Take a look at <http://www.antlr.org/doc/trees.html#Action%
> 20Translation>. ANTLR labels get transformed during translation; if
> I remember correctly, #label translates to labelAST and #label_in to
> label. You are probably reusing the input tree by accident here.
> Try replacing list with #list in the action.
>
> --Loring
>
> --- In antlr-interest at yahoogroups.com, "Arnar Birgisson"
> <arnarb at o...> wrote:
> > Hello again..
> >
> > I solved this problem by rewriting the transformation so that it
> worked
> > without the !. However, I keep hitting this wall in other places,
> and
> > now I'm completely stuck. Consider those (simplified) constructs
> in my
> > language
> >
> > f -> procedure()
> > var x
> > body
> > expression1,
> > block
> > x := \incr x,
> > \print [1,2,3]
> > endblock,
> > x := \incr ,
> > \print [1,2,3]
> > endbody
> >
> > Now.. the expressions "\incr x" and "[1,2,3]" have such trees:
> >
> > #([OPERATOR,"incr"] x)
> > #([LIST,"["] #([EXPR_LIST] 1 2 3) )
> >
> > and I have rules in my tree transformer that changes them to the
> > equivalent of the expressions "incr(x)" (function call) and
> > "mk_pair(1,mk_pair(2,mk_pair(3,[])))". This transformation works
> very
> > well for the second pair of those expressions.
> >
> > Now I want to make a transformation for turning
> >
> > BLOCK
> > |
> > EXPR_LIST
> > |
> > expr1 - expr2 - ... - exprN
> >
> > to
> >
> > expr1 - expr2 - ... - exprN.
> >
> > For this I have the rule alternative
> >
> > |! #(BLOCK list:expr_list)
> > {
> > ## = list->getFirstChild();
> > }
> >
> > This seems to work except that the transformations inside this
> instance
> > of expr_list don't get executed. Therefore, the transformation of
> the
> > code above is applied only to the second pair of afformentioned
> > expressions.
> >
> > I'm using exactly the same rule (expr_list) to traverse the list of
> > expressions whether they are inside the procedure body, or inside a
> > block. I'm stumped!
> >
> > If I remove the ! I get two copies of the subtree, one where
> > transformations have been applied, and one where they havent...
> >
> > Am I doing something terribly wrong or is this unexpected
> behaviour?
> >
> > Arnar
> >
> >
> > > -----Original Message-----
> > > From: mzukowski at y... [mailto:mzukowski at y...]
> > > Sent: 14. nóvember 2003 18:39
> > > To: antlr-interest at yahoogroups.com
> > > Subject: RE: [antlr-interest] Tree transformation
> > >
> > >
> > > Hard to tell. I recommend using -traceParser and following
> > > through the code
> > > to see what's happening.
> > >
> > > Monty
> > >
> > > -----Original Message-----
> > > From: Arnar Birgisson [mailto:arnarb at o...]
> > > Sent: Friday, November 14, 2003 7:24 AM
> > > To: antlr-interest at yahoogroups.com
> > > Subject: [antlr-interest] Tree transformation
> > >
> > > Hello..
> > >
> > > I'm having some trouble I can't figure out, possibly because I'm
> doing
> > > something stupid.
> > >
> > > I have this rule in a tree parser for transforming loops:
> > >
> > > loop_stmt
> > > : #(L_LOOP stmt_list)
> > > | #(L_WHILE expr stmt_list)
> > > |! #(L_FOR init:stmt_list test:expr incr:stmt_list
> > > body:stmt_list)
> > > {
> > > /* this changes "for" loops to "while" loops
> */
> > > antlr::RefAST newbody;
> > > antlr::RefAST lastBodyStmt =
> > > body->getFirstChild();
> > > if (antlr::nullAST == lastBodyStmt) {
> > > newbody = incr;
> > > } else {
> > > while (antlr::nullAST !=
> > > lastBodyStmt->getNextSibling())
> > > lastBodyStmt =
> > > lastBodyStmt->getNextSibling();
> > >
> > > lastBodyStmt->setNextSibling(incr->getFirstChild());
> > > newbody = body;
> > > }
> > > antlr::RefAST l = #([L_WHILE,"while"], test,
> > > newbody);
> > > antlr::RefAST lastInitStmt =
> > > init->getFirstChild();
> > > if (antlr::nullAST == lastInitStmt) {
> > > ## = l;
> > > } else {
> > > while (antlr::nullAST !=
> > > lastInitStmt->getNextSibling())
> > > lastInitStmt =
> > > lastInitStmt->getNextSibling();
> > > lastInitStmt->setNextSibling(l);
> > > ## = init->getFirstChild();
> > > }
> > > }
> > > ;
> > >
> > > Now, stmt_list is a simple rule
> > >
> > > stmt_list
> > > : #(STMT_LIST (stmt)*)
> > > ;
> > >
> > > and the stmt rule is a big rule, with one alternative being this
> > > (note that in my language there is no difference between
> > > statements and
> > > expressions):
> > >
> > > |! #(OPERATOR s1:expr s2:expr)
> > > {
> > > /* this changes "x <op> b" to the function
> call
> > > "<op>(x,y)"
> > > #OPERATOR->setType(ID);
> > > ## = #([OPEN_PAR,"("], ADGERD,
> > > #([stmt_list,"params"], s1, s2));
> > > }
> > >
> > > Now, this alternative successfully transforms operator
> statements to
> > > function alls when they are top level statements in functions
> > > (accessed
> > > throught stmt_list), but when they're in a for-loop body
> > > (named "body")
> > > in the above rule, no transformation takes place, i.e. #
> (OPERATOR expr
> > > expr) is left as is.
> > >
> > > I've tried removing the ! in the for-loop rule but that doesn't
> help..
> > > the transformation doesn't take place.
> > >
> > > Any ideas?
> > >
> > > Arnar
> > >
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > > Your use of Yahoo!
> > > Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
>
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list