Re: [Sbcl-devel] --load and undefined (CLOS) types

[William H. N. <wil...@ai...>]

On Sat, Feb 02, 2002 at 12:10:11PM +0100, Stig E Sandoe wrote:
> hei,

Hi. I finally have an Internet connection in my new apartment. Now
I can start replying to people again.

> I am currently testing with the 0.7.1 .deb and I found these two
> issues:
> 
> 1. There is no --load command-line command for loading lisp-files, 
>    which is typically provided by most lisp-environments.  It is 
>    quite useful for many purposes, so please consider adding it at some 
>    point. 

Is 
  $ sbcl --eval '(load "foo.lisp")'
not sufficient? I omitted --load in the interests of orthogonality,
thinking that the existence of --eval made it redundant.

> 2. When compiling code with CLOS-classes, it seems to have the same 
>    problem as in CMUCL with the CLOS-classes being undefined types in the 
>    same file:

Hmm, right. OK, this is bug 149 now. Thank you.

> In CMUCL this can be remedied by the hack:
>   #+pcl
>   (pushnew 'compile pcl::*defclass-times*)
> 
> However, interestingly enough, SBCL does not seem to provide the
> *features* :pcl or :sb-pcl for conditionalising on PCL, nor the
> *defclass-times* variable.  Is there a way to make SBCL understand that
> "yes, he has defined the class properly and does not really need a
> screenful of warning (for each occurence of CLOS-type use)"?

SBCL's CLOS is drifting away from pure PCLness, so I don't think a
:PCL entry in *FEATURES* would be appropriate. Of course, its
definition might be imprecise enough that we could get away with it;
but then I'm not enthusiastic about using imprecisely defined things
to control compilation, so I'd be skeptical even then.

> So I suggest that types are created after the compile/load/eval of
> a DEFCLASS and that for other pcl-specific hacks one can have a *features* 
> flag.

I'm reluctant to do this. One reason that SBCL's CLOS is drifting away
from PCLness is that there are some nasty hacks in there, and IMHO the
*DEFFOO-TIMES* settings are among them. *DEFCLASS-TIMES* can be used
to work around the bug 149 problem, but in general when you mess with
the *DEFFOO-TIMES* variables you pay a price by introducing new dain
bramage. (I don't remember the new problems offhand, but they've been
discussed on the CMU CL mailing list.)

Now that SBCL's version of CLOS no longer aspires to be portable, and
now that SBCL's EVAL-WHEN works correctly, it should be possible to
fix this bug properly (without *DEFCLASS-TIMES* hacks). Look at
(MACROEXPAND-1 '(DEFCLASS FOO () ())) and note that it's trying to do
INFORM-TYPE-SYSTEM-ABOUT-STD-CLASS. Currently
INFORM-TYPE-SYSTEM-ABOUT-STD-CLASS isn't doing enough to stop the
warnings, but it should be able to, perhaps by messing with
SB-C::*UNDEFINED-WARNINGS* here.

-- 
William Harold Newman <wil...@ai...>
"Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings 
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C