Re: refining the Synopsis APIs

On Friday 29 October 2004 18:13, Stefan Seefeld wrote:

> >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 diagrams I sketched out didn't convey the whole picture, as (for
> example)
> it doesn't talk about the type system used for the nodes, neither the API.
>
> If it were only for the omission of redundant information, I would
> certainly agree.
> I can see some value in both representations. However, I don't think the
> abstract
> syntax tree requires a separate representation. It can be a 'proxy API'
> that is provided via proxy nodes that are generated on-the-fly while
> traversing the
> parse tree. It only requires a special visitor to expose the AST while
> walking
> over the parse tree.

Probably. I'm only trying to avoid creating extra layers without pressing 
need. Do you think there's such need at the moment?

> >Why don't we name the module simply "Semantic"? Say:
> >
> >namespace Sematic {
> > class Class;
> > class Function;
> >        ..............
> >}
>
> How's this any less vague than 'ASG'. I believe that if ever there is
> meaning
> in one of those terms, it is because people recognize it and associate it
> with
> a specific domain / content (uh, that's almost tautological ;-)

Well, this eliminates two of three confusing words ;-)

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

> these are interesting questions I don't yet have any clear answers to.
> My feeling is that for clarity it would be best to keep the APIs separate
> (yes, I can see use cases where users want to access the lowest level, such
>  as when running tools that control / enforce coding conventions, or
> compute any form of low level metric). 

But that does not require unsafe access. Does any tool need to replace opening 
brace with class declaration, for example?

Maybe, each node in syntax tree should just be able to provide "raw" iterator 
over all tokens?

- Volodya