Re: fun with declarations and definitions

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Feb 05, 2009 at 02:41:00PM -0800, Christopher Li wrote:

> Can you elaborate the referential transparency? I currently have a vague
> idea of what you are trying to do. Where should I start if I am going
> to turn the idea into code. Should we delay the detail of type
> information until evaluate stage?

Basically, "replace equal with equal".  I.e. whatever we do with struct
symbol that might be visible to somebody, we should not change the
interpretation of type for *any* struct symbol, including ones that
might refer to that one.

Take a look at uninlining for a nice example of the fallout you get
when that property doesn't hold.  We cannibalize struct expression
during evaluation a _lot_, so we have to be bloody careful about what
we share and what we must copy.

For struct expression we do that in a lot of places and it's probably
worth to keep doing due to memory footprint concerns.  For types
we can avoid that.

As for the laziness - yes, that's what classify_type() et.al. is about.
We want to do exactly as little as possible; basically, *all* type
node evaluation (aka examining) should be demand-driven.  It mostly
holds, but we definitely could be lazier, e.g. in qualifier-related
stuff.

I'll do a more complete braindump (ideally - along with the declaration-parsing
patchset, so that this work could really start) once I dig myself from
under the !@#!@#!@# patch and mail piles elsewhere a bit.

			Al, terminally annoyed by the size of backlog ;-/