Re: refining the Synopsis APIs

On Thursday 28 October 2004 20:58, Stefan Seefeld wrote:

> >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.

It does not seems like ASG is equally common term. If it were, we would not be 
discussing the naming.

> >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. 

The diagram you've linked to does not make it clear for sure. In fact, the 
picture of syntax graph is the same a picture for AST, with added edges.

> Look at this example: 
>
> code
> ====
>
> int array[8];
>
> parse tree
> ==========
>
>         declaration
>       /  / | | \  \
>      /  /  | |  \  \
>  int array [ 8   ] ;
>
> AST
> ===
>
>         declaration
>          /   |   \
>        int array  8
>
> ASG
> ===
>
>        declaration
>         /      \
>       int[8]   array

Thanks for  drawing those, it makes arguing much simpler. I definitely don't 
want "AST" level as "parse tree" without braces. IMO, it does not bring us 
anything.

> 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).

I did not say there's no difference, I just objects to (mis)use of "Abstract" 
and "Semantic" words. Besides, "Graph" does not add much either, because 
every C++ structure with pointers can be seen as a graph. 

Why don't we name the module simply "Semantic"? Say:

namespace Sematic {
 class Class;
 class Function;
        ..............
}

> 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).

This proves that PTree is not safe, but it does not mean we need another 
level.

> An AST API could provide access to the parse tree that enforces these
> invariants.

Why can't "Syntax" layer be a single layer including safe invariant-preserving 
methods? Is it specifically needed to have unsafe methods. If we need both 
safe and unsafe ones, do we need two layers, with two different sets of 
classes and completely different behaviour? Can we have just one set of 
"Syntax" classes with safe and unsafe methods?

- Volodya