From: Stefan S. <se...@sy...> - 2004-08-10 11:40:02
|
Grzegorz Jakacki wrote: > One factor that makes this pattern messy in OpenC++ is that Walker > (ClassWalker, strictly speaking) performs not only context-dependant > analysis, but also source-to-source translation. yeah, and this is indeed where my confusion started. It would already be less confusing if there were multiple Walkers, one to finish the parsing, and others to do the mop stuff. >> Now, I believe it would be important to try to move this to a one-step >> parse, i.e. integrate the Environment building into the parser such that >> the parser can correctly deal with corner cases that used to be >> interpreted >> incorrectly. > > > This would be great, but I am afraid it is impossible. Consider: > > class A > { > void f() { g(); } > void g() {}; > }; > > So we are doomed to perform some form of two-pass analysis, in > particular binding cannot be performed together with parsing. Hmm, you are right. I'll have to look again into the gcc sources to see how they do it... > Apart of that, I still oppose integrating too much into parser. I > suggest functionally equivalent solution of making higher-level services > (e.g. environment creation, identifiers lookup) available to parser > through an abstract interface. That's what I'm thinking about indeed. The parser would have a reference to a 'SymbolTable', and each time it enters a scope it calls table->new_scope(), each time it runs into a declaration it pushes it into the current scope, etc. I'm still considering what it takes to make occ accept C code. The lexer is easy, as we can at runtime mask some keywords (i.e. report them as identifiers). The parser may be relatively easy, too, as we only have to exclude a number of productions and may be add one or two (C is almost a subset of C++). The SymbolTable finally would need some flexibility, too, as name lookup doesn't follow the same rules (well, there are far less rules to start with :-) Regards, Stefan |