[Synopsis-devel] Re: software design clarification

Gilles J. Seguin segg at infonet.ca
Wed May 9 19:50:08 UTC 2007


On Wed, 2007-05-09 at 14:35 -0400, Stefan Seefeld wrote:
> Gilles J. Seguin wrote:
> 
> > GCC and Synopsis parsers are identical at the behavior level.
> > For Type analysis Synopsis try to do same thing at same place
> > but is doing it partially or not at all.  That means GCC type analysis
> > can be hook up on Synopsis, the only major difference now is
> > the mangling.
> 
> Not quite. Algorithmically they may be similar (well, no wonder as
> I basically try to imitate what the 'new' GCC C++ compiler frontend is doing),

That is also just following a great common unifier that is the 
appendix a) of c++ standard.
You will have end-up with same file source.

> but the representations they build during parsing isn't the same (phew ! ;-) )

yup, ink colors are different.

> And, as a good chunk of type analysis has to be done during parsing (at
> least when following the GCC model), this can't easily be hooked up.

You just said that GCC is doing type analysis during parsing.
Synopsis is doing type analysis during parsing too, right ?

> So, it's really one or the other: if we use gcc as the C++ frontend,

> we have to read in the generated representation after the full parsing
> is complete.

GCC output full representation only when one function is present in
the source code.  That is, dumping the internal representation of
the body of that function.
That is, is you have the definitions of Main() and foo() functions,
only the declaration part will be given.

>  We certainly can't parse in Synopsis, feed the results to
> GCC for type analysis, and get the final results back.

That will be naive,
I said that during parsing, both GCC and Synopsis must either
fill the, what you call Symbol, or query the name-lookup.
And both are doing it at same time when questioning what is that token.
That is, we have done syntax analysis, look at same amount of tokens
forward and are still stuck, means the thing is ambiguous.
The ambiguity is resolved by doing semantic analysis.

Following GCC mechanism for semantic analysis will accelerate
that design section.

Final result must be homomorphism, will be very very unhappy if not.

> FWIW, the picture is basically the same with Keystone (where 'Token Completion'
> is used, what Markus appears to be alluding to). Elsa is different, as there
> multiple parse tree candidates are kept around, and the correct branch is then
> selected later on when some semantic analysis is possible.
> 
> Regards,
> 		Stefan




More information about the Synopsis-devel mailing list