CLOS, cold init, and other things (was Re: [Sbcl-devel] DEF!STRUCT answer)

[Nathan F. <fr...@ro...>]

On Mon, Mar 26, 2001 at 02:49:01PM -0600, William Harold Newman wrote:
> In the longer run, the more I've worked on the type system in 0.6.11.x
> (especially while adding INTERSECTION-TYPE, redoing the type methods,
> debugging a NUMERIC-TYPE problem) the more I wished that CLOS was set
> up in cold init, so that we could define fundamental things like type

Why can this not be done?  It doesn't seem like it should be *that*
difficult to me.  Then again, I may just be dreaming, as you are. :)

And while we're at it (you might explain it anyway), what's the
difference between cold and warm init?

> classes completely in terms of CLOS, without having to use pre-CLOS
> hacks like doing crude method dispatch without inheritance in
> !INVOKE-TYPE-METHOD, and faking up inheritance with (CASE
> (NUMERIC-TYPE-CLASS X) ..). I can't really tell how hard it would be
> to rearrange the PCL code so that it could be cross-compiled and
> cold-initialized; it might even be reasonably straightforward. (It
> might also be impossibly difficult, of course.:-) Maybe I'll give it a
> try one of these days, and see. If that could be done, then it would
> become possible to replace other CLOS-isn't-ready-yet hacks (like the
> DEF!STRUCT-TYPE-MAKE-LOAD-FORM-FUN stuff that's the problem here) with
> ordinary CLOS definitions, which would be a nice solution to problems
> like this. (It's a nice dream, anyway..:-)

In similar spirit, why is it necessary to work around the non-prescence
of CLOS?  I was under the impression that PCL (and therefore SBCL's
version of CLOS) was more of a bolt-on to the already existing type
system that just happened to work with classes rather than a fundamental
underpinning of the system.  Is this correct or not?
-- 
</nathan>  fr...@ro...  |  http://www.rose-hulman.edu/~froydnj/

Yes, God had a deadline.  So He wrote it all in Lisp.