BTW, just to clarify the l-t-v semantics: all dynamic variable bindings in the global and dynamic environments at load time are available, even though the null lexical environment has no bindings. The null lexical environment just prevents you from mixing up load time and execution time like this:
(let ((foo (print 10))) ; a lexical binding (load-time-value foo))
__Martin
On Tue, 3 Nov 2009 17:57:13 -0500, Derrell Piper said:
Yup, that fixed it, thanks!
On Nov 3, 2009, at 5:15 PM, Tobias C. Rittweiler wrote:
Derrell Piper ddp@electric-loft.org 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 that was a mistake on my part. Thanks for the report,
-T.
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel