8 missing bits in implementation

** all of the above

** reuse the same scratch package whenever a system is reloaded from disk

** rules for system pathname defaulting are not yet implemented properly

** proclamations probably aren't

** when a system is reloaded with fewer components than it previously had, odd things happen

we should do something inventive when processing a defsystem form, like take the list of kids and setf the slot to nil, then transfer children from old to new list as they're found

** traverse may become a normal function

If you're defining methods on traverse, speak up.

** a lot of load-op methods can be rewritten to use input-files

so should be.

** (stuff that might happen later)

*** david lichteblau's patch for symlink resolution?

*** Propagation of the :force option. “I notice that

(oos 'compile-op :araneida :force t)

also forces compilation of every other system the :araneida system depends on. This is rarely useful to me; usually, when I want to force recompilation of something more than a single source file, I want to recompile only one system. So it would be more useful to have make-sub-operation refuse to propagate :force t to other systems, and propagate only something like :force :recursively.

Ideally what we actually want is some kind of criterion that says to which systems (and which operations) a :force switch will propagate.

The problem is perhaps that `force' is a pretty meaningless concept. How obvious is it that load :force t should force compilation? But we don't really have the right dependency setup for the user to compile :force t and expect it to work (files will not be loaded after compilation, so the compile environment for subsequent files will be emptier than it needs to be)

What does the user actually want to do when he forces? Usually, for me, update for use with a new version of the lisp compiler. Perhaps for recovery when he suspects that something has gone wrong. Or else when he's changed compilation options or configuration in some way that's not reflected in the dependency graph.

Other possible interface: have a 'revert' function akin to 'make clean'

     (asdf:revert 'asdf:compile-op 'araneida)

would delete any files produced by 'compile-op 'araneida. Of course, it wouldn't be able to do much about stuff in the image itself.

How would this work?

traverse

There's a difference between a module's dependencies (peers) and its components (children). Perhaps there's a similar difference in operations? For example, (load "use") depends-on (load "macros") is a peer, whereas (load "use") depends-on (compile "use") is more of a `subservient' relationship.