[antlr-interest] Upgrade a token/AST from inside the parser.

Peggy Fieland madcapmaggie at yahoo.com
Thu Nov 17 07:45:02 PST 2005


You'll need to disambiguate dotted names.

I didn't do it this way  but I've been thinking about
pushing the 
business with the dot qualifier into the lexer and
then letting the
parser split the names into pieces as needed and tag
the pieces 
with SCHEMA, TABLE, COLUMN qualifiers. 

You want to avoid the syntactic predicates:
(a.b) =>

and use instead semantic predicates.  
{ LT(1)->getText() == "a" && LT(2)->getText() == "." 
&& LT(3)->getText() == "b"}?

There's been a lot of discussion about this on the
list -- check the archives.



--- "Jan H. van der Ven" <jhvdven at xs4all.nl> wrote:

> And the race condition is in
> ASTFactory:
>     public AST make(AST[] nodes) {
>         if (nodes == null || nodes.length == 0)
> return null;
>         AST root = nodes[0];
>         AST tail = null;
>         if (root != null) {
>             root.setFirstChild(null);	// don't leave
> any old pointers set
>         }
>         // link in children;
>         for (int i = 1; i < nodes.length; i++) {
>             if (nodes[i] == null) continue;	//
> ignore null nodes
>             if (root == null) {
>                 // Set the root and set it up for a
> flat list
>                 root = tail = nodes[i];
>             }
>             else if (tail == null) {
>                 root.setFirstChild(nodes[i]);
>                 tail = root.getFirstChild();
>             }
>             else {
>                 tail.setNextSibling(nodes[i]);
>                 tail = tail.getNextSibling();
>             }
> ---->            // Chase tail to last sibling
> ---->            while (tail.getNextSibling() !=
> null) {
> ---->                tail = tail.getNextSibling();
> ---->            }
> // bites its own tail
>         }
>         return root;
>     }
> 
> <quote who="Jan H. van der Ven">
> > Sorry my first response went out to you
> personally. Luckily the others did
> > not get my newbie response.
> > In the meantime i did some reading and coding and
> headstomping.
> >
> > My simplified statement parser now sometimes knows
> when it is dealing with
> > a table or a column but when i have a common
> construction like select
> > table.column from table my cpu rises to 100% even
> though my ambiguities on
> > this (there are 2 that I think do not matter) are
> resolved.
> >
> > I have attached my .g. The trouble is with the
> dbObject I think.
> >
> > The statement that's giving me headaches is:
> SELECT a.b from C (see how
> > far I am already ;-)
> >
> > Please advise.
> >
> > <quote who="Peggy Fieland">
> >> I use different token types in the parser, eg
> >>   SQL_E_COLUMN_NAME
> >>   SQL_E_TABLE_NAME
> >> usually in the case of column names, the actual
> name
> >> is a child of this node:
> >> Here is part of the column_name definition for
> one of
> >> the databases:
> >>
> >>  o0:schema_name DOT!
> >>             t0:table_name DOT! c0:column_name_ref
> >>             { ## = #([SQL_E_COLUMN_NAME,
> >> "COLUMN_NAME"], #c0, #t0, #o0); }
> >> ...
> >>
> >> --- "Jan H. van der Ven" <jhvdven at xs4all.nl>
> wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> I am currently working on a SQL parser (we want
> to
> >>> support all databases,
> >>> but I am taking baby steps). I used the MS SQL
> >>> select statement from
> >>> Tomasz Jastrzebski that can be downloaded from
> >>> antlr.org. It checks my
> >>> statements ok, but that is not the only result I
> am
> >>> looking for.
> >>>
> >>> What I want is that after the parsing the tokens
> >>> contain extra information
> >>> about their syntactic nature. For instance, the
> >>> parser will find out that
> >>> a certain 'identifier' is actually a column and
> I
> >>> would like that
> >>> knowledge to become part of the token or the
> AST.
> >>>
> >>> I am new to all of this, so if this is something
> you
> >>> guys do all day
> >>> please let me know.
> >>>
> >>> If it is not, could you point me in the right
> >>> direction.
> >>>
> >>>
> >>> Kind regards,
> >>>
> >>>
> >>> Jan van der Ven
> >>>
> >>>
> >>
> >>
> >
> 
> 
> 



More information about the antlr-interest mailing list