Re: refining the Synopsis APIs

Vladimir Prus wrote:

>>I hoped the term would be in common use in the compiler / parser
community,
>>and some search on google and citeseer seems to confirm this.
>
>
>You know, in my PhD research, "abstract semantic" means something
completely 
>different.

Yeah, but isn't that true for all terms ? Take 'extensible markup language',
for example. Pretty vague, if you don't spell it like 'XML', at which point
everybody (or almost) nowadays knows what you are talking about.

>Looking at the diagram, I don't think we require "denotional semantic". It 
>looks like semantic graph there is AST + extra edges.

I disagree. Have a look into the Synopsis.AST class hierarchy (as well as
Synopsis.Type): there is little or no relationship to the actual syntax
from which these objects are instantiated. So 'ASG' is not just an annotated

syntax tree, it is something entirely different, not isomorphic to the
syntax /
parse tree. Look at this example:

code
====

int array[8];

parse tree
==========

        declaration
      /  / | | \  \
     /  /  | |  \  \
 int array [ 8   ] ;

AST
===

        declaration
         /   |   \
       int array  8

ASG
===

       declaration
        /      \
      int[8]   array

The distinction between syntax and semantic layer seems to be clear
immediately
(I didn't even show an edge from referenced symbol to its declaration).

The distinction between parse tree and AST is less evident, but I believe
there
are good reasons to make the distinction nonetheless:

The PTree lets you traverse the nodes via 'car()' and 'cdr()' methods. Even
though 
individual nodes carry type information which is now made accessible through
the 
visitor pattern, it's dangerous because the encapsulation is very
incomplete. 
You can easily replace the 'typedef' atom in the 'PTree::Typedef' node by a
'class', thus
breaking an invariant (i.e. generating a syntax error).
An AST API could provide access to the parse tree that enforces these
invariants.

Regards,
		Stefan