Next: , Previous: , Up: Top   [Contents][Index]

14 Inspiration

14.1 mk-defsystem (defsystem-3.x)

We aim to solve basically the same problems as mk-defsystem does. However, our architecture for extensibility better exploits CL language features (and is documented), and we intend to be portable rather than just widely-ported. No slight on the mk-defsystem authors and maintainers is intended here; that implementation has the unenviable task of supporting pre-ANSI implementations, which is no longer necessary.

The surface defsystem syntax of asdf is more-or-less compatible with mk-defsystem, except that we do not support the source-foo and binary-foo prefixes for separating source and binary files, and we advise the removal of all options to specify pathnames.

The mk-defsystem code for topologically sorting a module’s dependency list was very useful.

14.2 defsystem-4 proposal

Marco and Peter’s proposal for defsystem 4 served as the driver for many of the features in here. Notable differences are:

The defsystem 4 proposal tends to look more at the external features, whereas this one centres on a protocol for system introspection.

14.3 kmp’s “The Description of Large Systems”, MIT AI Memo 801

Available in updated-for-CL form on the web at

In our implementation we borrow kmp’s overall PROCESS-OPTIONS and concept to deal with creating component trees from defsystem surface syntax. [ this is not true right now, though it used to be and probably will be again soon ]

Next: , Previous: , Up: Top   [Contents][Index]