Re: [Sbcl-devel] unicode progress (or lack thereof)

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

On Tue, Apr 30, 2002 at 07:38:02PM +1000, Brian Spilsbury wrote:
> Christophe Rhodes wrote:
> 
> >On Tue, Apr 30, 2002 at 02:03:38PM +1000, Brian Spilsbury wrote:
> >
> >>The only reason that the current sbcl/cmucl can't compile this is that 
> >>the current sbcl/cmucl is broken.
> >>
> >
> >Could you please provide more details?  Or are you referring to the fact
> >that cmucl and sbcl (validly) have no CHARACTERs that are not
> >BASE-CHARs?
> >
> The real problem is the bootstrap process is broken, and inherits much 
> type information that it should not.

Could you give an example?

(I know of one big sin in this department, that lots of IEEE floating
point behavior is, mostly implicitly, assumed to be present on the
cross-compilation host, mostly affecting calculation and folding of
constants. But the only such brokenness which affects characters, that
I can think of offhand, is the assumption that the xc host's BASE-CHAR
set is sufficiently ASCII-like that we can use
non-ANSI-Common-Lisp-standard whitespace characters like TAB and ^L in
the SBCL sources.)
 
> The conflation of base-char and character is one such inheritance that 
> should not happen.
> 
> Normally you can ignore it since cmucl and sbcl agree about most type 
> issues at that level.
> 
> >>Perhaps clisp will prove less broken for once, although I can't say that 
> >>I'm particularly optimistic.
> >>
> >
> >:-) well, no.  In this respect:
> >
> > [6]> (typep (code-char 1024) 'base-char)
> > T
> > [7]> (typep (code-char 2048) 'base-char)
> > T
> > [8]> (subtypep 'simple-string 'simple-base-string)
> > T ;
> > T
> > 
> >it looks like clisp also has everything as a BASE-CHAR...
> >
> Oh well, so much for that :)
> It won't avoid the bootstrap problem then.

I have never understood (or, speaking of unanswered questions, perhaps
have never seen?) your explanation of this bootstrap problem.
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? (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?

-- 
William Harold Newman <wil...@ai...>
"Palantir great. Better than cable."
  -- <http://home.nyu.edu/~amw243/diaries/saruman.html>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C