Re: struct environment

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

On Wed, 11 Sep 2002 14:36:28 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Wed, Sep 11, 2002 at 11:33:08AM -0700, David Carlton wrote:

>> But I think I was making too much of the memory-management
>> difficulties: I'll do iterators correctly (so you can have as many
>> of them active as you want), and just write an ALL_ENV_SYMBOLS
>> macro that allocates them on the stack using alloca().

> Or you could just require an iterator to be declared in the function
> which uses ALL_BLOCK_SYMBOLS.... why bring alloca into it?  The
> pointer you allocate into would need to be a local variable so the
> iterator might as well just be a local variable.  Sure, it makes
> them a tiny bit less opaque.  But make them opaque -in practice-.

I know, I'm too in love with opacity right now.  Chalk it up to the
bad influence of C++, or something.  (What, I can't just store my
pointer in a std::auto_ptr and have its contents deleted automatically
when it goes out of scope?)

Having said that, there's a bit more reason for these types to be
opaque than normal.  There will be multiple implementations of
environments: currently fixed-size hash, fixed-size linear, and
expandable linear (for use by jv-lang.c and mdebugread.c, sigh), plus
two temporary implementions using struct block that will only exist
until all the block code is switched over to using environments.  And
once I tackle global symbols, there will be at least one new permanent
environment implementation and one new temporary environment
implementation to handle that, too.  Also, there is literally no
information that is common to all the different implementations, so it
simply doesn't make sense to have publically-accessible macros to get
at parts of the environment, for example.  So it would be nice if,
say, adding new implementations was all localized to environment.c
plus adding one creation function prototype to symtab.h, rather than
polluting symtab.h with lots of data that only environment.c will use.

But, on the other hand, alloca() should still be avoided if possible.
And it's not like the solution using alloca() is all that clean: in an
opaque implementation, I can't alloca(sizeof struct env_iterator), so
I would have to provide a function call env_sizeof_iterator() to
return that information.  And I suspect that, once we move on to the
global environment, we'll want to add a 'parent environment' member to
environments that will be there for all implementations, so it might
make sense to make environments slightly less opaque.  It's even
possible that, for performance reasons, some of the functions will
have to be turned into macros eventually.

I'll think about it some more.  It might well be the case that all
iterators would just need a struct environment *, a struct symbol **,
and an integer: so they all have the same data, but use it in
different ways depending on how the struct environment is
implemented.  If that's the case, it would be perverse to use
alloca(): I can certainly break opaqueness to that extent.

David Carlton
carlton@math.stanford.edu