[slime-devel] CMUCL 20a startup issue
martin at lispworks.com
Wed Nov 4 11:24:05 UTC 2009
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
>>>>> 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 at 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 at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/slime-devel
> slime-devel site list
> slime-devel at common-lisp.net
More information about the slime-devel