Re: More-than-ASCII chars

[email protected] Mon, 20 Oct 2003 12:03:47 -0700 (PDT)
Newsgroups gmane.lisp.scheme.ssax-sxml
Message-ID <[email protected]>
Hello!

> I put my presentation on ILC2003 about multilingualization (m17n)
> support on Scheme on web, in which I suggested several operations
> that would be useful to write a portable Scheme programs
> across various implementations.

> http://www.shiro.dreamhost.com/scheme/docs/ILC2003.html

It's very interesting. I noticed that your proposal is consistent
with mine generalized i/o proposal and the proposal for left-fold
iterators to access collections (which underlies SRFI-44). The
generalized i/o proposal is specifically based on the idea of
overlayed, multiple-level streams.

BTW, Haskell (GHC, to be precise) also has packed strings, with O(1)
random access.  Also for the record: the language B, the predecessor
of C, had only packed strings. Therefore, a B programmer had to use
library functions to do string manipulations. Directly accessing
characters in a string was too much of a hassle.


> > Any Java/JVM-based Scheme system should have no problem with implementing
> > these [ucs2->char] functions.
> Ah, I'm afraid not.  How about &#10302; ---if the implementation uses
> utf-16, it has to become two characters, one's code is #xd800 and
> another's is #xdf02.

> > Indeed, according to the XML
> > Recommendation, all Kanji are considered letters and may appear
> > wherever an ASCII letter is allowed.

> That's nice.  Hmm, I need a rather large table to do that, though...

Not necessarily. The XML Recommendation defines allowable characters
merely by their ranges. All Kanji fit into
[86] Ideographic   ::= [#x4E00-#x9FA5] | #x3007
                       | [#x3021-#x3029]

Also, an application does not need to handle all characters with equal
efficiency. One may imagine that an application will handle characters
(decide their class, case-ness, collating order, convert to an
integer) within some subset of Unicode efficiently, and will consult
external tables for other subsets. Likewise, a string may have an
internal tag that tells if the string is made of only fast
characters. When installing an application, a programmer may specify
the most efficient subset. In a sense, the difference between fast
strings and slow strings is akin to the difference between fixnums and
bignums.



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54