opencxx-users

Re: [Opencxx-users] symbol lookup

[Grzegorz J. <ja...@ac...>]

Stefan Seefeld wrote:
> Grzegorz Jakacki wrote:
> 
>> I don't pretend to understand all the details of how it works, but I 
>> think there is more to it than you describe. Look at 
>> 'SearchBaseOrUsing()', which to my understanding handles the 'forks' 
>> in the acyclic graph.
> 
> 
> you are right. I was puzzled by the 'GetOuterEnvironment()' call...
> 
> However, I must admit that I don't quite like the current design.
> As different context require different loopup rules, an IMO better
> approach would have been to provide a polymorphic 'Scope' type
> and then implement it differently for 'Function', 'Class', 'TemplateClass',
> etc. Then each scope would know the rules of where to look if a symbol
> isn't defined locally. This would be more flexible and in particular
> allow to implement different lookup semantics depending on whether
> we are parsing C++ or C. What do you think ?

Generally looks good. Questions:

* Scopes would replace Environments, right?
* What would be connection between Scopes and other objects
   representing e.g. functions or classes ?
* Who would own Scopes?

> 
>> Also note that OpenC++ is non-validating, consequently it rightfully 
>> ignores, say, ambiguities in multiple inheritance.
> 
> 
> yeah, I notice that the current implementation isn't complete.
> 
>>> Does symbol lookup currently work in such cases ?
>>
>>
>>
>> Why not check empirically?... :-)
> 
> 
> heh, right. That brings me back to the other point: unit testing.
> Now that the release is out (congratulations !) we should try to
> cover as much as possible with unit tests so we can a) make sure
> changes don't incure regressions and b) learn how occ works in detail.

That's right. I suggest, however, to cut off the core part of OpenC++
and now focus on unit tests for this part only.

BR
Grzegorz

> 
> Regards,
>         Stefan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] symbol lookup

[Stefan S. <se...@sy...>]

Grzegorz Jakacki wrote:

>> However, I must admit that I don't quite like the current design.
>> As different context require different loopup rules, an IMO better
>> approach would have been to provide a polymorphic 'Scope' type
>> and then implement it differently for 'Function', 'Class', 
>> 'TemplateClass',
>> etc. Then each scope would know the rules of where to look if a symbol
>> isn't defined locally. This would be more flexible and in particular
>> allow to implement different lookup semantics depending on whether
>> we are parsing C++ or C. What do you think ?
> 
> 
> Generally looks good. Questions:
> 
> * Scopes would replace Environments, right?

yes. 'Scope' would be an abstract base class with methods 'declare'
and 'lookup', as well as a hash for the locally declared symbols.
Subclasses would then implement 'lookup' to not only search locally
but in 'outer' scopes, too, according to the specific lookup semantics
of functions, classes, template classes, etc.

> * What would be connection between Scopes and other objects
>   representing e.g. functions or classes ?

Scopes are associated with those objects that are, well, scopes.
Right now I would probably do this in a simple dictionary, but
once we are getting into the AST stuff we could rethink about
this.

> * Who would own Scopes?

Good question. Who's using them ? The parser of course, would
need them, and all the Encoding / TypeInfo instances need them.
May be we need to keep to maintain a 'scope graph' in parallel
to the parse tree / syntax tree. As there are arbitrary many
references to any given scope may be it's a good idea to make
scopes reference counted.

Regards,
		Stefan