On Sun, May 8, 2016 at 11:28 AM, Faré <fahree@gmail.com> wrote:
clean-op is an impossible operation to fix, because its meaning isn't
defined in general, and CANNOT be defined in general. And while some
specific subsets and variants of it CAN be defined, they remain so
specific as to not be of general purpose and/or there are enough
subtly different variants of it to require a breakdown of the vague
idea into clearly separated concepts.

For instance, in the context of using git, you might "just" do a:

git clean -xfd

and call it quits. Yet, unless you specifically configured your
output-translations to point to under the current git repository,
it won't clean your fasl-translated cache, which would be in e.g.

~/.cache/common-lisp/ccl-1.12-f102-linux-x86/home/fare/common-lisp/arnesi/

Then comes the question: should clean-op clean only for the
current implementation, or should it also remove objects for
sbcl, ecl, allegro, etc.? A git clean might erase files that
you'd like to preserve, that you failed to git add. A

        rm -rf ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/home/fare/common-lisp/arnesi/

would fail to remove fasls from dependencies or on other
implementations. You could try

        rm -rf ~/.cache/common-lisp/ccl-1.12-f102-linux-x86/

or even

        rm -rf ~/.cache/common-lisp/

but then that might remove too many things, including things you might
like to keep at that time. And if you have a non-standard
configuration for output-translations, this might still miss some
files you might want to remove.

These certainly are dicey issues given the default mapping of output files.

Something I've been looking into is moving towards "project-based" CL development.  Most other languages now have some variant of this, where dependencies and build artifacts are typically contained within some sub-directory.  At this point in time, it's surprising that ASDF/Quicklisp doesn't do things this way.  I've only found one project attempting to do this,

https://github.com/fukamachi/qlot
(after a quick read, I don't think it's mapping output-files underneath the project directory like one might expect)  

If you only expect to load files from within that project/directory, and run separate lisp images for different projects/directories, then cleaning is more intuitive for those coming from mainstream environments, i.e. you just delete the build/ sub-directory.  I'd be interested to hear about similar approaches and complications, e.g. you'd want a user-global quicklisp cache to avoid re-fetching remote deps as in Maven with its ~/.m2. 

--
Ian Tegebo