William Harold Newman wrote:
>(I hope this message isn't a duplicate or otherwise messed up. I did
>the infamous upgrade of sendmail from 8.11 to 8.12 this weekend, and
>I'm still trying to straighten out the consequences.)
>On Mon, Apr 29, 2002 at 05:42:24PM +1000, Brian Spilsbury wrote:
>>Well, given the lack of discussion, I'm inclined to proceed as I see
>>fit, which will be more or less along the lines of my last post.
>>If this causes inconvenience further down the track, that's too bad.
>>I have things to get done, and I cannot keep on waiting for a week on
>Sorry. It isn't even that I've been too busy to reply, but I reacted
>badly to the perceived tone of your previous message, throwing up my
>hands and stalking away from my computer, and I never got back to it.
>from your previous message:
>- I am not going to write the code to make the current versions of
>- sbcl/cmucl bootstrap this, someone who find this a major priority is
>- welcome to do so.
>Well, I certainly find this a major priority. They say "never say
>never", so: if I get a lot of pressure from people I respect (or
>better yet, compelling arguments from people I can understand) to
>merge the patches into SBCL even though they make SBCL
>unbootstrappable, then maybe. Failing that, the patches are extremely
>unlikely to be accepted until bootstrappablized, whether at your hand
>or someone else's.
>Furthermore, since your personal style grates on my nerves (as, trying
>to be fair, I suspect my style grates on yours), and since I have no
>personal need for Unicode, the likelihood that your unbootstrappable
>code will be cleaned up at my hand seems pretty low right now.
What grates on my nerves is the repetition of questions which have been
answered months before, along with requests that something which can't
effectively be broken up be broken up into smaller pieces.
You can cut those datafiles off, but pretty much anything else, and it
won't compile, that patch is more or less minimal to get the system to
boot, with some test code from the last version left over, and the
datafiles for testing.
The only reason that the current sbcl/cmucl can't compile this is that
the current sbcl/cmucl is broken.
Perhaps clisp will prove less broken for once, although I can't say that
I'm particularly optimistic.
Having already hacked around this lossage once, I do not care to do so
>- I will need the unicode form to be default, and then to later produce
>- code to make it efficient for the cases where extended character sets
>- are not utilised. It is not workable to maintain such fundamental
>- disparities for such minimal returns.
>I didn't really understand this. First, when you write "I will need"
>it sounds as though you're talking about stuff that you expect us to
>do for you, but I can't figure out what. Second, when you say unicode
>form will be "the default", do you mean what you wrote elsewhere.
I have very few expectations at this point.
However what that meant is that "to do this practically we can't expect
to mantain both the broken code which conflates character and base-char
as well as where they are properly separate."
It means that I'm not going to attempt to maintain the #!-unicode stuff,
and will elide it presently.
There's no point - it doesn't give any real advantage, and has many
The correct solution is to support strings specialised onto
character-repertoires, and to support translation between a repertoire
and the unicode form where necessary, since base-char-reg is already 32
bits, it should be no burden to support 32k of 8 bit repertoires, and
256 16 bit repertoires.
The only cost coming when different repertoires are used together,
although it might take a bit of doing to make the primitive sufficiently
This will allow europeans to run in random 8 bit charsets without
penalty (as long as the streams share the same representation -
otherwise you'll have a small mapping cost). It will also allow CJK to
use 16 bit charsets in a similar fashion, while retaining integration
with the full unicode set.
> have already produced, but with the
> - character data-base files removed, and the #[!][+-]unicode options
> - removed to make the unicode form default
>so that if we apply your patch, SBCL will be always be compiled into a
>with-Unicode form even for people who don't need or want Unicode? This
>might be OK, and certainly isn't the same sort of nearly-nonnegotiable
>issue as making SBCL unbootstrappable. However, you should realize
>that doing things this way will probably raise the bar on the quality
>(not just correctness, but size and performance as well) for your
>patch to be considered for inclusion. (Maybe a lot, depending on how
>many users and developers really want Unicode.)
I've come to the conclusion that the only way to move forward is to do
so separately, and to expect no co-operation.
Fortunately I have downloaded the cvs snapshot from sourceforge, so it
should not cause any futher inconvenience to yourself.
If at some point you want to try to re-integrate these things, then you
can do so, if not, that's fine too.