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 ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
