[asdf-devel] ? on `dependency` [ Re: Trying again

[james anderson]

good morning;

what is a 'dependency'? the word makes my head spin.
in a build system, three things contribute to the completion state of  
any given node with respect to a given operation.[1] [nb. i refrain  
here from using the term 'depends on'.]
- any intrinsic performance. eg, for a system, the up-to-date  
instantiation of the system definition or for a source file, that it  
compiled.
- the performance with respect to internal constituents. eg, for a  
group (that is, a system or a module), the 'components'.
- the external requirements. eg, as expressed in .asd as :depends-on  
or :weakly-depends-on

the determination for a given node depends on the intrinsic  
evaluation and on evaluations delegated to constituents and  
requirements. the internal determination is customarily, effectively  
atomic. the others are unclear. in particular, whether and in which  
manner the completion state of external requirements is transitive is  
a 'completely open question'. the answer, below, reads as if the  
state propagates from external requirements in some selective, but  
unspecified, manner. otherwise changes to foo-implementation would  
indicate the foo-interface had changed, which would be seen by foo- 
user as an indication that it itself was not complete.

this needs to be made explicit.
the present definitions express only the user-to-requirement  
propagation rules.
this problem demonstrates that one must also be able to describe the  
inverse propagation rules.
in that the description of a system must include the rules for  
completion state propagation for respective operations.
maybe that applies to modules as well?
maybe that applies even to the level of components? eg for a source  
file changes to function, macro, ... definitions.

---
[1]: http://github.com/lisp/de.setf.asdf.x/blob/ 
285a38e4ee18e10b5ce887d8ab2dd5e2d352aa0a/asdf-x.lisp#L2152
On 2010-02-11, at 05:38 , Faré wrote:

> On 10 February 2010 18:27, Robert Goldman <rpgoldman at sift.info> wrote:
>> OK, I have just pushed an alternative solution to the module  
>> dependency
>> bug, this one (I believe) only triggered by INTRA-system  
>> dependencies.
>> This one is also on the module-depends branch.
>>
> A test! This requires a test case in the test suite (and not a suit in
> the suitcase).
>
>> This was achieved, as I said, at the cost of some hair, but I  
>> believe it
>> does the right thing to the extent that I understand the right thing,
>> and thinking about James's email convinced me that I /don't/  
>> understand
>> what is the right thing with respect to inter-system dependencies.
>>
> I think you do understand the right thing, and that James is wrong to
> want ASDF to somehow DWIM.
> If you want to distinguish in code into parts that are depended on and
> parts that are not, then split your code into two systems.
> System foo-interface provides the interface, with packages, macros,
> specials, types, classes, gfs, and anything that matters at
> compile-time.
> System foo-implementation provides the implementation, with everything
> else. Clients depend on foo-interface and get recompiled if the
> interface changes. The overall system depends on interface AND  
> implementation.
>
> In other words, on top of a system that does the Right Thing(tm), i.e.
> invalidate dependencies recursively, you can do whatever you want,
> though it may take some effort. On top of a broken system, you always
> and forever have something broken.
>
>> Somewhat disappointingly, this commit agrees with the last one on the
>> tests, which indicates that the tests need to be augmented...
>>
>> Additional reviews very welcome as are test results!
>>
> No time for that right now. Hopefully tomorrow.
>
>
>> [Fare: is your XCVB going to handle the kinds of inter-system  
>> issues I
>> raised in my earlier email?]
>>
> XCVB does the Right Thing of correctly invalidating any object any
> dependencies of which has changed. On top of that, you can do whatever
> you want.
>
>> Feeling like Richard III, I can only say "A spec!  A spec!  My  
>> kingdom
>> for a spec!"
>>
> I think ASDF should, like XCVB, do the Right Thing, which is obvious:
> a dependency is a dependency. Just like any build system on earth
> does. Just because legacy ASDF is broken doesn't mean it should remain
> so. Incremental builds are broken with ASDF, and that's a shame.
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http:// 
> fare.tunes.org ]
> There is no excuse for a programming language without clean formal  
> semantics.
> For even if your language is not designed for formal reasoning by  
> computers,
> there will still be humans who'll have to reason about programs.
>
> _______________________________________________
> asdf-devel mailing list
> asdf-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel