[asdf-devel] launchpad bug-502946 [ Re: New module-depends branch contents pushed

[Robert Goldman]

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