From: William H. N. <wil...@ai...> - 2002-04-30 15:36:04
|
On Wed, May 01, 2002 at 12:23:55AM +1000, Brian Spilsbury wrote: > William Harold Newman wrote: > > > > >I have never understood (or, speaking of unanswered questions, perhaps > >have never seen?) your explanation of this bootstrap problem. > > > Well, I've answered this question a few times now. > > >Fundamentally I don't see why the +Unicode cross-compiler can't be > >written in terms of ANSI Common Lisp, without depending on a dialect > >which implements characters other than STANDARD-CHAR and which makes a > >distinction between BASE-CHAR and CHARACTER. The cross-compiler > > > >generates code which deals with characters other than STANDARD-CHAR, > >but why does the host Lisp need to know about them? > > > It can, and is written in terms of ANSI Common Lisp. > > The host doesn't need to know, and in fact does not know. > > It is the target's use of the host's type-system to build parts of > itself, in the bootstraping, which causes the problem. > > >(aside from the > >trivial reason of dealing with TAB and ^L in the SBCL sources) Writing > >a cross-compiler which supports types not supported in the host > >language isn't weird rocket science, it's standard practice. What's > >different here? > > > > The problem is that the bootstrap doesn't work to redefine existing > types which it can't distinguish. > > In cmucl and sbcl character is aliased to base-char... > > So, when sbcl bootstraps, and it uses host's type definitions to build ^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^? > your defknowns, etc, where you write 'character' it writes 'base-char'. ^?^?^?^?^?^?^? > The next phase inherits the broken defknowns, and naturally the next step is > > ***boom*** > > It is a bit more complex than that iirc, but that's the gist of it. Well, OK, I am somewhat familiar with misbegotten interactions between the host type system and the cross-compiler type system, having done a fair amount of work to remove them in the process of making SBCL bootstrap itself.:-| What I don't see is why they show up here. (And beyond that what I really don't understand is why when they show up here, you consider them a feature, or at least an unavoidable part of bootstrapping Unicodeness, and not a bug.) You do say something about where host/xc type system interactions show up, talking about DEFKNOWNs in particular. Ordinarily I would expect that the types which appear in DEFKNOWNs should be used only by the cross-compiler's type system (i.e. turned into SB!KERNEL:CTYPE objects by calls to SB!KERNEL:SPECIFIER-TYPE, and then further manipulated by other machinery in the SB!KERNEL package). Evidently, from what you say about "uses host's definitions", they're also being passed to the *host's* type system (with CL:SUBTYPEP or whatever). If I could see how that is happening, I'd probably consider it a fairly fundamental problem in SBCL and be interested in fixing it. > You are welcome to look at the hacks to get around it which are in the > sbcl-0.6.13-unicode patch. Right. I grepped for "defknown" in the sbcl-0.7.0-unicode.p0 patch, and didn't get any immediate insights. Perhaps this is a blind spot of mine, where I've been able to overlook a rat's nest of dependency bugs because the xc hosts I've worked with have always been too similar to the target I'm creating. But blind spot or whatever, I would probably recognize it faster if I got a more specific hint than "the problem is implicit in the uncommented workaround hacks in this multi-megabyte patch of mine [which incidentally also implicitly conveys my working estimate of the value of others' time compared to mine, since I can't be bothered e.g. either to remove irrelevant files or to provide a summary which would let the reader confidently determine for himself which files are irrelevant]". -- William Harold Newman <wil...@ai...> "Programming should be fun, programs should be beautiful." -- P. (Paul?) Graham, quoted in comp.lang.lisp by David E. Young PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |