Re: other char/string things

Tom Lord <lord-1tv/[email protected]> writes:

> It's been called to my attention that I forgot to specify a "control"
> buckybit.  Oops.

I recall pointing that out to you and getting a response rationale of
something like "control is something special and will be handled
elsewhere/differently."  :-P

> Just for the record, what we eventually need to tweak-things into
> is to have:
>
> 	C-
>
> as a character name prefix, mean to set the control buckybit.
>
> Thus, 
>
> 	(char->integer #\C-a)
>
> is some large integer -- not U+0001

That shouldn't be too hard to add.  At the moment it's mostly a
non-issue, but since you mentioned sorting on character value (which
includes buckybit value) perhaps it would be worthwhile to give some
thought to a stable ordering for the buckybits?

> Additionally, character _names_ (not bucky-like prefixes) are needed 
> for ASCII control characters:
>
>
> 	ctl-a		== U+0001
>         ctl-[		== U+001B
>         ctl-@		== U+0000
>         ctl-space	== U+0000
>
> etc.

Again, this should be easy to add since the lexing code won't mistake
any of those as buckybits.  (Is ctl-space really U+0000?)

> We currently have four buckybits and adding control will make five.
>
> I think that there is a total _possible_ number of 8 buckybits
> (because 32 == 21 + 8 + 3 and 3 == log_2(8) and 2*sizeof (t_scm_word)
> is 8 on a 32 bit machine --- in other words,
>
> 	tag-bits + codepoint + buckybits == 32

(Just wait until 64-bit PCs become common and we can have 40 buckybits
-- emacs users' heads will explode trying to remember all the
commands. :-)

> [stuff regarding reserving two bits]

I can't admit I fully understand the rationale of it, but I'll give it
a few days to try to sink in before questioning it.  I said before I
had a few other things I was working on, but luckily none of them
demand any buckybits allocated to them. ;-)

-jivera