[Openmcl-devel] Plans for Unicode support within OpenMCL?

[Takehiko Abe]

Pat Lasswell wrote:

> > If having multiple string types is not desirable, I think UTF-16
> > string is a good compromise. The 4-fold increase of string size
> > is too much.
> >
> 
> A 4-fold increase is too much?   While I don't advocate that the
> hardware requirements of OpenMCL keep up with Moore's Law, it seems
> that bits and flops are so cheap that a little extra string storage
> isn't going to be noticed in amonst the mp3s and jpegs.

I don't think "a little extra string storage" is an accurate
description. It's 4x increase of what you have.

Say you read 100k ascii (or latine-1) text file into buffer,
the buffer needs to be 400k in size (if the string is 32-bit).
If input is 1000k, the buffer will be 4000k. and so on.

I believe that having multiple string types is better.
(If Moore's Law also applies to processor speed, then we can
perhaps ignore a little bit of extra cpu cycles?)

MCL has extended-string which is 16-bit and I like it. I like
it perhaps because I have never cared how it is implemented.
And crucially, Gary doesn't like it (or doesn't seem
enthusiastic about it.)