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

[Monty Zukowski]

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/