[antlr-interest] Re: tree recognition during multiple passes

[excel_robot]

Thanks for that Mr Zukowski.
Its great to get feedback like this and to point me in the right
direction. 
I have finished a little example but I'm not happy with it. So I will
be starting fresh and Ill implement a grammar which can recognize both
source and target AST as you suggest.
I'm also going to have a talk with my manager about the benefits of
expert advice and see how things go on that front ;)

Thanks a million for your time,
Dermot. 
--- In antlr-interest at yahoogroups.com, Monty Zukowski <monty at c...> wrote:
> On May 10, 2004, at 10:25 AM, excel_robot wrote:
> 
> > Thanks for your fast reply.
> > I work for Oracle and I'm researching transformations between SQL
> > dialects.
> 
> I just finished a SQL grammar for use in a product that needs to 
> translate into different SQL dialects.
> 
> > I was thinking about what things I would do in the passes.
> > I had the following choices
> > 1) Would each pass handle one SQL statement( one for the select
> > statement, one for the update statement ...)
> > or
> > 2) Would the first pass handle expressions, the second pass handles
> > all DML ...
> >
> 
> I recommend 2) because it keeps the  translation organized by concept.
> 
> > If I went the second way with the following simple example.
> > SELECT col1 + 2 FROM table1
> >
> > my source AST would look like this
> > SELECT
> > |-SELECT_LIST
> > | |-+
> > |   |-col1
> > |   |-2
> > |
> > |-FROM
> >   |-table1
> >
> >
> > My first pass would change the expression
> > SELECT
> > |-SELECT_LIST
> > | |-TARGET_AST
> > |   |-col1
> > |   |-2
> > |
> > |-FROM
> >   |-table1
> >
> > Then I couldn't recognize the SELECT_LIST as it was half source AST
> > and half target AST
> >
> > Its easy enough for me to create the source AST grammar and the target
> > AST grammar.
> > I think what your saying is that I write a new AST grammar that can
> > recognize both.
> >
> > select: #(SELECT select_list from)
> > ;
> >
> > select_list: #(SELECT_LIST
> >                  #((operator|TARGET_AST) // choice between source and
> > target AST's
> >                       column number)
> > ;
> >
> 
> You got it.
> 
> >
> > I see what you mean but I was hoping too keep things as neat as 
> > possible.
> > If the source or target AST changed then I would have to update this
> > into my grandaddy of all grammars
> > I used to think super grammars could combine a source and target AST
> > for me but after reading a few of your own articles I realized thatH
> > this is not what they are for.
> >
> Yep.  I would consider noweb or writing your own simple preprocessor.  
> The join points for your grammar will be very simple to author, a 
> simple include mechanism would allow you to keep separate .g files for 
> source & target.
> 
> > Maybe I should just transform entire sub trees to the target and not
> > worry about having a sub tree which was a combination of both.
> > Im only working on a simple prototype at the moment but Im trying to
> > think of some of the big issues and approaches.
> >
> That forces you to translate it all in one pass.  No chance to handle 
> expressions separate from DML.
> 
> I'm also available to discuss this by phone and/or consult if you would 
> like some more intense conversations about this.  
> http://www.codetransform.com
> 
> Monty



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/