Re: [RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton <carlton@math.stanford.edu>]

On Tue, 17 Sep 2002 12:29:47 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

> - create a header ``dictionary.h'' / ``nametab.h'' / ... that defines
>   the interfaces for this new object.

Sure.

> - macro's are bad m'kay :-)

Even accessor macros for members of structures?  Gee, I like those:
it's a lot easier to find all places where, say, struct block's
'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
than by grepping for 'hashtable' and then sorting out which ones of
those really are referring to the 'hashtable' member as opposed to
some other use of the phrase.

Admittedly, that's less important here since the structures in
question are opaque, so they'll only be accessed within one file.  So
if you want me to move away from them, that's fine; I was just trying
to follow existing practice in symtab.h and gdbtypes.h.

The macros that are currently used (as seen in
<http://sources.redhat.com/ml/gdb-patches/2002-09/msg00202.html>,
modulo replacing 'environment' by 'dictionary', not just in the
smaller portion of it that I recently put up for RFA) fit (I think!)
into the following taxonomy:

* One-argument accessor macros for members of structures.
* Two-argument accessor macros for members of structures that are
  arrays: these accessor macros take the index into the array as a
  second argument.
* Symbolic constants.
* ALL_DICT_SYMBOLS, to make looping over all the symbols easier.

I think the only macro that is publically accessible is
ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface
to iterating over symbols in dictionaries is a lot easier than the
interface to iterating over symbols in blocks.

So if you want me to get rid of all macros (other than, presumably,
symbolic constants, though I could use the enum trick there), I can
certainly do that.

> - just implement interfaces sufficient for the immediate needs.  For
>   instance, instead of providing ``enum dict_type'', just describe
>   the idea.  Since we can compile with -Werror, changing internal
>   interface, when there is evidence that it is actually needed, has
>   become relativly easy.

dict_type really is necessary currently: I need to provide hash tables
and linear environments to support the existing functionality of
blocks.  It's just like the 'hashtable' member of struct block.

> - keep gdbint.texinfo in mind

Right.

> - you'll want to start compiling all targets

Sure.  How do I go about doing this?  I don't have access to a wide
range of machines; are there machines at Red Hat that I can use?

David Carlton
carlton@math.stanford.edu