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> froydnj@... | http://www.rose-hulman.edu/~froydnj/
Yes, God had a deadline. So He wrote it all in Lisp.

Martin Atzmueller wrote:
>
> Hi,
>
> when I compile a file containing the following
> (using either sbcl-0.6.11 or the newest CVS-snapshot):
>
> (in-package :cl-user)
> #p""
>
> I get:
>
> * ;;;Compile pathname-dump-bug.lisp
> ; compiling file "pathname-dump-bug.lisp" (written 22 MAR 2001 11:03:49
> AM):
> ; byte compiling top-level form:
> ; compilation unit aborted
> ; caught 1 fatal ERROR condition
> ; compilation aborted after 0:00:00
> "ILISP:
> error in function SB-C::COMPILER-ERROR:
> (while making load form for #<SB-IMPL::UNIX-HOST {501A1C5}>)
>
> error in function \"DEFMETHOD NO-APPLICABLE-METHOD (T)\":
> There is no matching method for the generic function
> #<STANDARD-GENERIC-FUNCTION
> MAKE-LOAD-FORM
> (6)>
> when called with arguments (#<SB-IMPL::UNIX-HOST {501A1C5}>
> #S(SB-KERNEL:LEXENV
> [ - snip - ]
> )
> *
>
> As far as I was able to track it down, this happens, because
> make-load-form is
> not specialized on COMMON-LISP:STRUCTURE-OBJECT, but on
> SB-SYS:STRUCTURE!OBJECT.
> And SB-IMPL::UNIX-HOST is a subtype of COMMON-LISP:STRUCTURE-OBJECT, but
> not of
> SB-SYS:STRUCTURE!OBJECT.
Trying a little further:
The comments in the source-code say, STRUCTURE!OBJECT is only used
internally,
but is otherwise equal to STRUCTURE-OBJECT, but only includes an extra
make-load-form-fun slot, that is, what we need.
So, UNIX-HOST is made a subtype of HOST, but the type HOST is not
defined
anywhere, as far as I could find out.
All that seems to be a bootstrapping problem, because of make-load-form
only
working with STRUCTURE!OBJECT but not with STRUCTURE-OBJECT.
(SPECIFIER-TYPE 'HOST) returns a STRUCTURE-CLASS, and this one is - as
expected - a subclass of STRUCTURE-CLASS.
Maybe it would suffice to add a definition for HOST somewhere ...?
But how does HOST as a type come into existence, in the first place.
Grepping through the sources did not reveal anything, and I stepped
down till VALUES-SPECIFIER-TYPE which gives me some instance,
that somehow exists ... ( magic ? :)
--
Martin Atzmueller <martin@...>

William Harold Newman wrote:
>
> On Fri, Mar 23, 2001 at 03:07:05PM +0100, Martin Atzmueller wrote:
> > Martin Atzmueller wrote:
> > > when I compile a file containing the following
> > > (using either sbcl-0.6.11 or the newest CVS-snapshot):
> > >
> > > (in-package :cl-user)
> > > #p""
> > >
> > > I get:
> > >
> > > * ;;;Compile pathname-dump-bug.lisp
> > > ; compiling file "pathname-dump-bug.lisp" (written 22 MAR 2001 11:03:49
> > > AM):
> > > ; byte compiling top-level form:
> > > ; compilation unit aborted
> > > ; caught 1 fatal ERROR condition
> > > ; compilation aborted after 0:00:00
> > > "ILISP:
> > > error in function SB-C::COMPILER-ERROR:
> > > (while making load form for #<SB-IMPL::UNIX-HOST {501A1C5}>)
[ - snip ]
> > All that seems to be a bootstrapping problem, because of make-load-form
> > only
> > working with STRUCTURE!OBJECT but not with STRUCTURE-OBJECT.
> > (SPECIFIER-TYPE 'HOST) returns a STRUCTURE-CLASS, and this one is - as
> > expected - a subclass of STRUCTURE-CLASS.
> > Maybe it would suffice to add a definition for HOST somewhere ...?
> HOST is defined in pathname.lisp. The menagerie of cold-init/bootstrap
> variants of the DEFFOO forms is admittedly an obstacle to finding
> things, but it can be found:
Thanks.
The attached patch should fix the problem (a simple test case is
included, too).
(The patch also includes a fix for a trivial FIXME note.)
The problem was, that a structure defined by DEF!STRUCT (UNIX-HOST),
that includes a structure defined by DEFSTRUCT (SB!XC:DEFSTRUCT),
somehow loses its ability to have a "make-load-form-fun",
because it has no STRUCTURE!OBJECT superclass, but only
a STRUCTURE-OBJECT, and for that the right make-load-form-fun
is not found.
I have two question:
What exactly does the comment in code/defstruct.lisp, line 214
";; FIXME: MAKE-LOAD-FORM is supposed to be handled here, too.",
mean?
The separation of DEF!STRUCT and DEFSTRUCT structures seems to be
problem sometimes, so, is a structure defined by DEFSTRUCT supposed
to have a special make-load-form-fun, or not?
--
Martin Atzmueller <martin@...>

On Mon, Mar 26, 2001 at 01:32:45AM +0200, Martin Atzmueller wrote:
> The attached patch should fix the problem (a simple test case is
> included, too).
> (The patch also includes a fix for a trivial FIXME note.)
OK, thank you.
> The problem was, that a structure defined by DEF!STRUCT (UNIX-HOST),
> that includes a structure defined by DEFSTRUCT (SB!XC:DEFSTRUCT),
> somehow loses its ability to have a "make-load-form-fun",
> because it has no STRUCTURE!OBJECT superclass, but only
> a STRUCTURE-OBJECT, and for that the right make-load-form-fun
> is not found.
>
> I have two question:
> What exactly does the comment in code/defstruct.lisp, line 214
> ";; FIXME: MAKE-LOAD-FORM is supposed to be handled here, too.",
> mean?
I think it refers to the discrepancy between the comments at the head
of the function, which date back to original CMU CL, and what the
current version actually does. Something should change to make the
comments consistent with the code, and at the time I wrote the FIXME
it wasn't obvious which should change. It still isn't instantly
obvious. I'll probably look at it a little more after I get
sbcl-0.6.11.26 to a state where I can check it in.
> The separation of DEF!STRUCT and DEFSTRUCT structures seems to be
> problem sometimes, so, is a structure defined by DEFSTRUCT supposed
> to have a special make-load-form-fun, or not?
My tentative answer, which might turn out to be at least somewhat
wrong, is that SBCL, unlike CMU CL, tries diligently to use CLOS as
ANSI specifies for things like PRINT-OBJECT, DESCRIBE-OBJECT, and
MAKE-LOAD-FORM. However, some DEFSTRUCTs need to be compiled before
CLOS is running, so we need a special hack to deal with MAKE-LOAD-FORM
in that case. Those which need that hack, and perhaps some others as
well, are built with DEF!STRUCT. By limiting the hack to only some
classes internal to the system, rather than user-defined classes, the
hack can be fairly crude and still not cause problems.
(DEF!STRUCT handles other stuff as well, notably the magic required to
dump a cross-compilation host Lisp object as a compiled target Lisp
object.)
I should probably document the design motivations in the DEF!STRUCT
system more properly somewhere. It's part of the weird complicated
system intended to make cross-compilation host Lisp objects correspond
to target Lisp objects, and even though I wrote it, I was unable to
make it simple, so it usually takes me a while to stuff it back into
my head when I need to understand it again. Better documentation would
both give me something to point to to answer questions like yours, and
help me in the stuff-it-into-my-head process.:-|
--
William Harold Newman <william.newman@...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C

On Mon, Mar 26, 2001 at 01:32:45AM +0200, Martin Atzmueller wrote:
> The problem was, that a structure defined by DEF!STRUCT (UNIX-HOST),
> that includes a structure defined by DEFSTRUCT (SB!XC:DEFSTRUCT),
> somehow loses its ability to have a "make-load-form-fun",
> because it has no STRUCTURE!OBJECT superclass, but only
> a STRUCTURE-OBJECT, and for that the right make-load-form-fun
> is not found.
>
> I have two question:
> What exactly does the comment in code/defstruct.lisp, line 214
> ";; FIXME: MAKE-LOAD-FORM is supposed to be handled here, too.",
> mean?
> The separation of DEF!STRUCT and DEFSTRUCT structures seems to be
> problem sometimes, so, is a structure defined by DEFSTRUCT supposed
> to have a special make-load-form-fun, or not?
OK, now maybe I understand better what you were saying.
The requirement that any class :INCLUDEd by a DEF!STRUCT be defined by
DEF!STRUCT, not just DEFSTRUCT, can be a problem sometimes, since it's
easy to inadvertently get it wrong, and the system doesn't catch the
problem at compile or build time, but only when someone tries to dump
an instance of the class. I'll try to add such a check to the
DEF!STRUCT macro to catch problems like this in the future; I can
probably do this while I'm merging your patches,
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
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..:-)
--
William Harold Newman <william.newman@...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C

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> froydnj@... | http://www.rose-hulman.edu/~froydnj/
Yes, God had a deadline. So He wrote it all in Lisp.

On Tue, Mar 27, 2001 at 03:52:33PM -0500, Nathan Froyd wrote:
> 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. :)
I haven't looked at it enough to say, but just the way that so many
things change their behavior depending on SB-PCL::*BOOT-STATE* leaves
room for a lot of weirdness, if e.g. macro expansions depend on
generic functions calls which get dispatched differently depending on
the phase of the moon^H^H^H^H boot sequence applies. And in two failed
attempts to get my mind around _The Art of the Meta-Object Protocol_,
I haven't yet found any bounds on the bootstrap weirdness in PCL..
> And while we're at it (you might explain it anyway), what's the
> difference between cold and warm init?
Cold init is basically stuff that happens before you can get a command
prompt, or what happens in !COLD-INIT before the tail call to
TOPLEVEL-INIT.
SBCL's warm init is the stuff that happens after it's sane enough to
display a command prompt and compile files and stuff, but it still
hasn't compiled and loaded various required things like CLOS and
DESCRIBE. It's basically the stuff that happens in src/cold/warm.lisp.
> > 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?
Certainly right now it's not a fundamental underpinning of the system.
Basically, I'm fantasizing about letting it become a fundamental
underpinning of the system. Right now nothing which is needed at the
beginning of warm init, in particular nothing needed by the compiler,
can be implemented in terms of CLOS, which is a drag. If CLOS could be
set up in cold init, that would change.
There are two issues here, I think:
(1) The type system doesn't understand CLOS very well, and hasn't
been completely updated to work with CLOS. There are mismatches
between SB-PCL:X and CL:X for important values of X, like CLASS,
FIND-CLASS, and STANDARD-CLASS.
(2) The type system is implemented in terms of a cobbled-together
system of class definition (!DEFINE-TYPE-CLASS) and method
dispatch (!DEFINE-TYPE-METHOD, !INVOKE-TYPE-METHOD). This
really doesn't work all that nicely, since this system
lacks things like inheritance, leading to kludges like
the CLASS slot of NUMERIC-TYPE (which expresses variants
which would be better represented as true subclasses).
It would be nice to have CLOS available in warm init, so
that it would become possible to reimplement this stuff
using CLOS. (It mightn't be much fun to try to rewrite it all
at once, but it would be nice to be have the opportunity
to rewrite any part which happens to be causing problems at
the moment.) There are also some other cobbled-together things
which could benefit from CLOSification (like MAKE-LOAD-FORM
for DEF!STRUCT, and various ETYPECASEs in the implementation of
the compiler), and it's not an option right now because they're
needed in warm init; but if CLOS could be set up in cold init,
it would become an option, and that'd be nice in the same way.
I wasn't talking about issue (1), though it's seems as though you
might (understandably) have thought I was. Issue (1) has come up
repeatedly on the CMU CL mailing list (and maybe on the SBCL list too,
I don't remember), and every knowledgeable person seems horrorstruck
at the idea of straightening it out. I might contemplate straightening
it out some day, but I have no hope that it will be surprisingly easy
-- "predictably excruciating" is my guess. Issue (2) is what I was
discussing in the quoted passage, and I don't remember seeing it
discussed much before, probably mostly because it's not an end-user
problem, and perhaps partly because it's not the kind of maintenance
that the CMU CL maintainers are motivated to do. Now that I've started
thinking about it, I have some hope that it might be surprisingly easy
to do. But, because of *BOOT-STATE* and whatnot, it might turn out to
be pretty nasty too. It's hard to say with any confidence without,
basically, just trying to do it. Very likely someday I'll try it, but
I have no idea when.
--
William Harold Newman <william.newman@...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C