Re: [rfc] struct dictionary

[David Carlton <carlton at math dot stanford dot edu>]

On Tue, 29 Apr 2003 11:10:05 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
>> 

>>> Ok, humor me ...
>>> http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
>>> build these data structures during symbol reading?  It takes time
>>> and space, yet is probably never used.  Why not on-demand build this
>>> dictionary specialized for the block?
>> That sounds great to me if we can get it to work.  It's certainly

>> another reason to try to get the symbol lookup stuff abstracted behind
>> an opaque interface: it makes lazy loading of data a lot easier.

> But which interface?

> A block has a language, and [I think] it's the language that, in the
> end decides that block's name->symbol lookup strategy.  The language
> can, on demand, build a dictionary for its block.

Currently, all uses of symbols in blocks either iterate over all
symbols or else are looking for symbols with a given natural name.  As
you say, because of the features of certain languages, sometimes you
need to refine the search further beyond that, but that's a good first
cut.  So having iterators dict_iterator_{first,next} and
dict_iter_name_{first,next} is a good first step: it unifies all the
existing mechanisms for symbol lookup, but doesn't commit to any sort
of implementation mechanism.  It certainly would allow for
constructing the actual data structures on demand: for example, we
could add an implementation that doesn't actually build the data
structures storing the symbols until the first time that an iterator
is called.

I'm certainly willing to believe that the interface might change in
the future; but separating the interface from the implementation is a
good first step no matter what.

I kind of get the impression that I'm missing your point somehow and
that we're talking past each other.  I'll post a concrete patch soon
(Wednesday, maybe?  It's done on my laptop, but I don't have my laptop
with me), and hopefully that will clarify matters.

David Carlton
carlton@math.stanford.edu