* Derrell Piper [2009-11-03 20:49+0100] writes:
I promise to crawl back into my cave shortly...
CMUCL 20a is barfing in swank-arglists when starting up SLIME from fasls. It loads fine on the initial compile pass but when it's just loading the swank-arglists fasl, it gets confused somewhere in here (contrib/swank-arglists.lisp):
(in-package :swank) ... (eval-when (:compile-toplevel :load-toplevel :execute) (defparameter +lambda-list-keywords+ '(&provided &required &optional &rest &key &any)))
(defmacro do-decoded-arglist (decoded-arglist &body clauses) (assert (loop for clause in clauses thereis (member (car clause) +lambda-list-keywords+))) (flet ((parse-clauses (clauses) (let* ((size (load-time-value (length +lambda-list-keywords+)))
At first, I assumed this was some sort of bug in CMUCL having to do with package interning and (load-time-value...) although now that I've read the HyperSpec on (load-time-value...) that's less clear. The CLHS says that (l-t-v...) is evaluated in a "null lexical environment" which the glossary says is, "the lexical environment which has no bindings." And since the current package is bound to *package* what CMUCL is doing would seem to be correct. As an experiment, I tried adding explicit package qualification to all of the references to +lambda-list-keywords+ and CMUCL still signals the same error. In other words, CMUCL goes out of it's way to lose the package specifier in (l-t-v...).
And yet this code is working in SBCL and Clozure... Can anyone explain what's broken where any maybe suggest a workaround or a fix? I'll be happy to go report this to CMUCL if need be. Thanks!
I think it's the CMUCL bug related to c::top-level-lambda-max. CMUCL reads that many toplevel forms and compiles them together as one block. Doing so should give the compiler a larger optimization window, but unfortunately CMUCL doesn't preserve the order of some load-time actions as it should.
I don't know why load-time-value is used here. Maybe a mundane #. would do the job?
Helmut