[asdf-devel] More ASDF changes ahead

[Faré]

Since I'm waiting for some clients to make appropriate changes
before I may release ASDF (notably FSet and GBBopen),
I'm considering making a few additional backward-incompatible changes
in interfaces that I believe are not otherwise used
(after grepping for code in quicklisp).

The crux of the change is that I would like to move to a model where
operations are a place-holder with zero content besides the class name
— or failing that, a model where the timestamps are associated to
a specific instance of an operation, not a class name,
at which point memoization of "equivalent" operations
is necessary for #'equal hash-tables to contain timestamps.
This is not just a matter of taste, but also of correctness:
if the semantics of two instances of an operation is actually different,
then considering one is done when the other was done is incorrect
— yet that's what ASDF currently does.

I recently added a PLAN object for the purpose of traversals, which
made it possible for ASDF and POIU to share the TRAVERSE algorithm.
(Incidentally, it also makes ASDF look more like XCVB or LIL.)
I'm moving :force and :force-not to this PLAN object,
removing them (and :verbose) from OPERATION,
removing the whole OPERATION-ANCESTOR crud
(which was only a dirty way of having the ancestor operation object
behave as a kind-of backassward plan object) and
having a global hash of *OPERATIONS* that are EQUAL
iff created with the same initargs.

Now for issues:
* swank.asd relies on OPERATION-FORCED for some obscure RELOAD feature.
  I think this is a mistake. I'll discuss that with the slime developers.
  Meanwhile, I'll keep it aroud through a stub for backward-compatibility.
* GBBopen (again!) uses operation initargs to determine
  the name of an application to be built. I think that's a mistake.
  This information should be in the component.
  I'll discuss the matter with the GBBopen developers.
  Meanwhile, I will keep the initargs around for backward-compatibility.
* the :on-failure and :on-warnings flags to operation
  don't actually work well with the new model,
  and had quite fishy semantics in the old one.
  Grepping through quicklisp-distributed code,
  it looks like no one is actually *using* it,
  though it's been cargo-culted in a few places.
  I will remove it, just keeping a few stubs for backward-compatibility.
  In practice, the only thing that works is to either
  bind *compile-file-on-warning-behaviour*
  and/or *compile-file-on-failure-behaviour* around the build, or
  equivalently pass :on-warning and/or :on-failure arguments to operate.
  The internal ASDF machinery that used to make that happen
  is horribly complex (what with make-sub-operation,
  now called find-operation, to pass along the flags
  from each operation to the next in the traversal),
  and does no more than if operate just recognized those keywords
  to bind those variables — which is my proposed interim solution
  (the defaulting based on a dynamic variable otherwise breaks my model
  of operations being equal if created from the same keyword arguments).
  I don't like those variables, especially since
  they mean subtly different things on different implementations
  (as usual CLISP being an outlier), but
  I'll have to think on how to best eliminate or replace them.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
To surrender to ignorance and call it God has always been premature,
and it remains premature today.		— Isaac Asimov