>>>>> "Camm" == Camm Maguire <[email protected]> writes:
Camm> Greetings, and thanks so much! I think we are converging...
Camm> 1) The proposal under consideration is due to Carl, that gcl's lisp
Camm> character still be governed by char-code-limit==256, i.e. equivalent
to
Camm> an uint8_t. aref/aset work the same for all types of arrays. This
lisp
Camm> character has no correspondence to a unicode character other than the
Camm> overlap in the ascii range. In some fashion, gcl would then provide
on
Camm> top of these primitives (unichar s i), etc. to get unicodes from utf8
Camm> encoded strings. These are not random access, but can be cached. So
Camm> (code-char #xa0) != no-break-space.
Have you considered the cost of making gcl really rather incompatible
with other CLs?
Having (code-char #xa0) not be no-break-space is going to have be
explained to users. I suspect mal-formed strings will be somewhat
common when someone accidentally stores a code-unit > 128 into a
string.
And why complicate thins with a cache? What was fairly simple now
depends on having a fast bug-free cache implementation.
--
Ray
_______________________________________________
Gcl-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gcl-devel
