[slime-devel] CMUCL 20a startup issue

[Helmut Eller]

* 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