Tobias C. Rittweiler wrote:
Just a guess, but what I could imagine that `parse-first-valid-form-spec' in swank-arglist.lisp could possibly be the culprit, as it uses the "mapping on several lists, one being circular" trick:
(mapcar #'+ '(1 2 3 4) '#1=(10 . #1#))
I'd expect this one to return (11 12 13 14), but closely rereading the CLHS entry for the mapping functions, reveals that those are actually only defined for /proper lists/.
Actually, ABCL seems to handle this form ok, returning the expected (11 12 13 14). And ABCL can compile PARSE-FIRST-VALID-FORM-SPEC from swank-arglist.lisp.
The problem ABCL seems to be once again [1] in its MOP when it attempts to compile the DEFMETHODs for EXTRA-KEYWORDS with the first argument specialized on (EQL 'MAKE-INSTANCE).
The following blows ABCL up with an unprintable (by SLIME) backtrace:
;;; From SLIME 'contrib/extra-keywords.lisp' r1.5
(defgeneric extra-keywords (operator &rest args) (:documentation "Return a list of extra keywords of OPERATOR (a symbol) when applied to the (unevaluated) ARGS. As a secondary value, return whether other keys are allowed. As a tertiary value, return the initial sublist of ARGS that was needed to determine the extra keywords."))
(defmethod extra-keywords ((operator (eql 'make-instance)) &rest args) (multiple-value-or (apply #'extra-keywords/make-instance operator args) (call-next-method)))
Is this something one could (and should?) reasonably expect to be de facto portable behaviour? IOW, am I to blame, or is ABCL?
I don't really feel qualified to answer about portability: all I can offer is that ABCL seems to understand the idiom correctly, but I haven't looked at the relevant code in the reader.
[1]: See the discussion around http://thread.gmane.org/gmane.editors.j.devel/1397 for context.