On 2/10/10 Feb 10 -2:05 PM, james anderson wrote:
good evening;
my usual question: is this necessary in this form? i pose the question from the perspective that a change from a context free interpreter to a context-sensitive one is rather more drastic than just getting dynamic bindings right. two simple questions occurred immediately.
the change reads as if any link to a predecessor entails a recursive dependency? does this really mean that, if one file changes three levels down in a referenced module, the entire referencing module is to be forced? would there not be advantage to introducing a "recursively-depends- on" relation to the effect?
Yes. That's what it means. E.g. if you have changed the definition of a system X and system Y depends on X, system Y will be recompiled.
I'm with Fare in thinking that this is desirable. If I change an upstream library, I don't want to have stale dependent files lying around. This is a conservative approach, but I'm willing to spend the machine cycles to save me the subtle oddities that occur when downstream Y is stale wrt X.
The problem is that, given the class structure in ASDF (system ISA module), it is very difficult to do something more refined without breaking this case:
(defsystem foo :components ((:file "file1") (:module "quux" :depends-on ("file1") :components (:file "file2"))))
In this case, in classic ASDF, a change to "file1" will /not/ trigger a change to "file2".
the asdf notation expresses two related, but independent constraints ambiguously, in that the only means it has is the appearance of a requirement in a list, despite that the actual constraints are operation order and, in addition, operation necessity.
is it true that both are always intended? is so, in what remains to "module" from any of the associations of "modularity", if in fact the respective constituents are not dependent? isn't this some manner of abstraction destruction?
I disagree in two ways:
1. I don't think module has strong meaning. It just means "intermediate component," IMO.
2. You can't have abstraction as in other languages in CL because CL does not have defined interfaces. You can't tell, in the X, Y case above, whether a change to X has changed the API wrt Y or not. To do so you would have to grovel over the definitions of X arbitrarily deeply. I haven't thought about this hard enough even to determine whether this operation is decidable... In that circumstance, you are left with either (a) conservative approach, recompile Y, or (b) optimistic approach, assume Y is still valid. I have a personal preference for (a) (I prefer to expend my Mac's cycles in place of my own) and believe that (a) is further indicated because it's much cleaner to fix the intra-system module dependencies in ASDF if you take approach (a).
We should probably explore this issue more deeply before we close it out --- that's why this is being done on a branch!
I have a follow-up about incorrectness of the conservative approach which I will send later.
Best, r