While I don't agree with you about how debuggable ASDF is, nor the how understandable are its failures, I DO agree with your feelings about keeping the error simple.
Most of the error components I was suggesting do not provide useful information to the user.
For the user, the important information is "why is this not supported?" and that has to do with static information the programmer should supply, rather than with information about what the current information is.
E.g., if an operation isn't supported on LispWorks 6.1, it doesn't help to tell the user that they have LW 6.1: it helps to tell them why it's not supported.
So what if I back off on making this more complicated, and we put in just a capability name (which may be helpful to match both for testing and for programming)?
That said, I would like feedback on how best to give feedback that's helpful to the user. E.g., if a features is not supported on LW 6.1 (but is supported on 7.0) or ABCL, then it's probably best for the ABCL user to get an error message that the feature is not supported on ABCL, but the LW user should get a message saying it's not supported on 6.1... if this is possible without too much effort.
What about the following candidate?
(with-upgradability () (define-condition unsupported-functionality (error) ((functionality :type string ;short name of functionality :initarg :functionality :reader functionality) (reason :initarg :reason :type (or string nil) ;format string :reader reason ) (reason-args :initarg :reason-args :type list :reader reason-args )) (:report (lambda (c s) (with-slots (functionality reason reason-args) c (if reason (format s "~a is not supported in this environment because ~?" functionality reason reason-args) (format s "~a is not supported in this environment." functionality)))))))
If this seems reasonable, I will start testing it by trying to put it in place of less specific calls to error.
One question I had was whether this should be a sub-class of SIMPLE-ERROR, and instead of REASON and REASON-ARGS, I should have used the standard FORMAT-CONTROL and FORMAT-ARGS. Those names are more informative about what the argument should be, but less informative about how the arguments will be used (since in this case they will be combined with the FUNCTIONALITY).
Thanks, r