[Synopsis-devel] Re: software design clarification
Gilles J. Seguin segg at infonet.caWed May 9 19:50:08 UTC 2007
- Previous message: [Synopsis-devel] Re: software design clarification
- Next message: [Synopsis-devel] Re: software design clarification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Synopsis-devel] Re: software design clarification
- Next message: [Synopsis-devel] Re: software design clarification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Synopsis-devel mailing list