Re: names of symbols

["Paul N. Hilfinger" <hilfingr at otisco dot mckusick dot com>]

David,

> > 2. This makes me wonder a little about cross-language
> >    queries---e.g., asking for an Ada symbol from C++ code.  How does
> >    C++ know to mangle?  Well, probably the solution of using 'set
> >    lang ada' temporarily in this case isn't so terribly bad.
> 
> Yeah, that's a good question.  We might be able to get this to work
> without that being necessary - the language is stored in the symbol,
> after all - but I could imagine problems arise.

Another possibility is simply to have SYMBOL_MATCHES_NATURAL_NAME be sensitive
to the current language as well as the symbol's language.  

> > 4. As to other bits: what did you think of my suggestion of handling
> >    multiple matches with a version of symbol_lookup that takes a
> >    call-back as argument (i.e., to be called with each matching
> >    symbol)?
> 
> Hmm.  My instinct is to use iterators for stuff like that (see
> dictionary.h for an example).  On the one hand, I feel a little guilty
> about that, because that's more a C++-style idea instead of a C-style
> idea.  But they're a little more flexible than callbacks: they work
> just as well as callbacks if you're trying to take an action on every
> symbol, and they work better if you're looking for a specific symbol
> and want to stop once you've found it.

Well, not necessarily.  I had in mind a callback signature like this:

      int (*callback) (struct symbol* sym, void* data);

The callback's return value indicates whether to continue the search or halt.

However, iterators work for me, too.  The callback scheme is usually easier 
on the fellow implementing the collection type, whereas the iterator scheme
is easier on the fellow using the collection type.  And since you would 
presumably be the former and I the latter....

	      - * -

I thought of one other little piece that might be useful:

  SYMBOL_COMPARE_NATURAL_NAME (symbol0, symbol1)

to be used for anything that needs to sort an array of symbols by natural
name.  Reason: this facilitates a design in which we never have to 
materialize a demangled name except transiently (for printing).  

Paul