[asdf-devel] The future of ASDF (was logical pathnames)

Robert Goldman rpgoldman at sift.info
Wed Mar 31 13:46:59 UTC 2010


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.

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:

http://cs-www.cs.yale.edu/homes/dvm/papers/lisp05.pdf

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.

Autoconf and make are not the tools for people who want to be able to
keep their lisp sessions running for days, weeks, or even months at a
time.  To do that one must integrate building and loading.

To borrow an analogy from Mikel Evins, the lisp session is a world that
one creates, and which one can occupy.  In this way it is radically
different from building software in C, for example.

Best,
r




More information about the asdf-devel mailing list