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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.