Re: refining the Synopsis APIs

Vladimir Prus wrote:

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

[...]

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

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

>>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 as I said, I don't think theres a need
for
the abstract syntax to be generated as a whole. Instead, it could be a
higher-level
view on the parse tree (using proxies).

Regards,
		Stefan