Re: refining the Synopsis APIs
Stefan Seefeld <[email protected]>
| Newsgroups | gmane.comp.documentation.synopsis |
|---|---|
| Message-ID | <[email protected]> |
Hi Gilles, Gilles J. Seguin wrote: >>The *SymbolTable* is what we are currently working on. It stores type- and >>other information about declared identifiers. Some of this information >>is required to disambiguate certain C++ expressions, and so the construction >>of the datastructure has to be done during the parsing. > > > The doc. thesis of Malloy, define two SymbolTable: > ASTSymbolTable and ASGSymbolTable. [for the record: the thesis we are talking about was written by Tanton H. Gibbs, Brian A. Malloy was the advisor.] > Since 'ASG processor pipeline' will work primarily on ASG. > I would have suspected this decoupling to appears in your module > description. > > Does your description will be subject to further refinement > of the SymbolTable or your analysis concluded that it is not required. That's an interesting question. I'm not sure. I understand that the parser only needs a subset of the information the symbol table will eventually provide. However, it's not clear to me that this means the approach taken by keystone, to construct a preliminary symbol table and later generate a refined one, is required. The way I currently see it (though that's of course all subject to refinement) is to keep the symbol table a separate module (in the module view, not necessarily the deployment view) that is filled during the parsing as much as possible, and if necessary (as the keystone paper seems to suggest) additional passes are required to complete it, do that. Remember also that, while AST and SymbolTable complement each other, the ASG's nodes are already interconnected. Of what use is a symbol table in this representation ? Regards, Stefan