as is evident from the message attached below, for the past several days i have thought about things related to bug-502946, and asdf in general.

my state-of-mind as of last week was, for the reasons alluded to below, that it is not productive to try to reason about system construction issues in the concrete context of asdf, -1.502, as it was at the time. i do not refer to with matters of configuration, or pathname mapping, or even 'elegant' bootstrapping, but rather to the need for a platform on which to think about and implement tools to

- manage systems with articulated interfaces

- manipulate system definitions programmatically

- automate system definition construction and maintenance

the larger concerns for integration with production, build, and deployment systems do all matter, just not right now. if one would set out the tasks in more detail, one could think about how to approach the issues, but at present, it is difficult to think even just about how asdf works.

the only reasonable approach was to take asdf apart, isolate the functional components and reassemble them in a manner which allows to think about how a tool to manage program components works and how it might work. the current state is captured in de.setf.asdf.x[1]. there is a readme[2], which describes the intent, and the asdf-x.lisp[3] file, which reimplements asdf.lisp. there is also a unit test[4] which captures one interpretation of the 'strongly-dependent' requirement relation.

on one hand, as a radical rational reconstruction of the original, it does not contribute to the main stream. on the other, the result provides the terms to think about what "intra-system" dependency is and a concrete context in which to implement projective proposals. cf. the commit[5] to support strong dependency by adding a state variable to the constraint machinery and adding the declaration to control it to the system definition language. most of which took the form of additional methods.

[5]: http://github.com/lisp/de.setf.asdf.x/commit/285a38e4ee18e10b5ce887d8ab2dd5e2d352aa0a

Begin forwarded message:

From: james anderson <james.anderson@setf.de>
Date: 2010-02-07 23:45:56GMT+01:00
To: rpgoldman@sift.info
Subject: Re: [asdf-devel] Launchpad bug 502946

good evening;

you may, or may not be expecting this, but i got tired of trying to understand traverse.
and tired of trying to understand parse-component, and defsystem, and pathname resolution, and ...
i am now about 3/4 through rewriting asdf with clear protocols for
- definition operators (at all three levels - system, module, element)
- perform - with distinct qualifiers for requirement (dependency, constituency) traversal, restart
- requirement and constituency specification canonicalization
- status evaluation for completion, features, other arbitrary predicates
- settings/environment assertions per component
- pathname resolution which does not depend on the quirks of *default-pathname-defaults*

it's about the same amount of code - even though many of the internal operators are decomposed to make the mechanism explicit.

the most unsettling part is to ensure that - between the bnf in the docs and the logic of the code, i've gotten the dependency definitions right, but it won't be long. i've been chewing through this since friday, so maybe by the time you're up tomorrow, there will be some code up in github which passes the tests. the intent is plug-compatible for the things i can understand, and i'm putting it in a new package, so with a couple package-name swaps, one can try things side-by-side. i will let you know.

On 2010-02-07, at 22:40 , Robert Goldman wrote:

Wrt https://bugs.launchpad.net/asdf/+bug/502946,
module is not recompiled if _intra_-system dependency changes, I have
spent quite some time groveling over the source code to TRAVERSE, and I
believe that this is going to be quite difficult to fix. There are a
number of assumptions baked into TRAVERSE, and some complicated uses of
a variable scoped over the body of TRAVERSE, together with a number of
local functions and a soupcon of unstated assumptions.

I'm pretty sure that modules are substantially broken and, in the short
term, I would discourage ASDF system designers from using them at all.

I have been banging my head on this for at least a working day's worth
of hours, and I need someone with whom to discuss the code, either by
voice, IM or IRC. Email is not going to be high enough bandwidth.

If anyone is interested in this enough to share the pain with me, please
drop me a line and we can coordinate.

Thanks,
r

_______________________________________________
asdf-devel mailing list
asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel