On 2010-03-31, at 15:46 , Robert Goldman wrote:
By and large I agree with Juanjo's statement of principles, but I would like to discuss the reason /why/ ASDF is different from tools like Autoconf.
Lisp development --- at least for people like me --- is primarily an interactive process, and this is why building and loading/executing are /inextricably/ linked.
It is, IMO, /not/ a handicap that ASDF performs both building and loading tasks, because Lisp software is not like conventional software.
In particular, this apparent duality ceases to become a source of confusion/dismay, if one stops thinking of "building" and "loading" and thinks instead about maintaining the integrity of a running lisp image.
Building and loading are just pieces of that integrity maintenance process.
I am with Juanjo in wanting to see the process of integrity maintenance become more declarative, and less cluttered with arbitrary procedural code. But I don't think that decoupling building and loading is particularly desirable in general.
i am at a loss as to how it would be possible with the level of information in an asdf system definition. i admit there is this class named asdf:compile-op, but i have never made an explicit reference to it.
if the system is small enough, compilation speed is sufficiently extreme that there is no case to track internal component dependencies. for systems which find themselves with thousands of load->compile dependencies, the only hope is for progress in dvm's direction.
every production lisp can save an image. maybe there's a commercial perspective which would see value in versioned fasl components, but it i have yet to.
For an extreme perspective on this issue, I'd encourage interested readers to look at Drew McDermott's paper on his integrity maintenance approach based on arbitrary chunks of code (a finer granularity than source files), where, for example, one can define dependencies needed to compose a hash table, so that its correctness (integrity) can be restored when data structures on which it depends are mutated:
ok, but it leaves me wishing even more for the paper which really really attends to just the "what".
This is admittedly an extreme, but it shows a purpose that systems like ASDF can serve --- maintaining the integrity of a running lisp image over extremely long periods of time.
it's not extreme. it is just an unfortunately neglected direction.