[r6rs-discuss] perhaps i should be formal, but....

From: Shiro Kawai <shiro>
Date: Thu Mar 15 01:53:05 2007

From: MichaelL_at_frogware.com
Subject: Re: [r6rs-discuss] perhaps i should be formal, but....
Date: Wed, 14 Mar 2007 23:49:47 -0400

> But any Scheme with a good foreign interface will have to deal with char
> strings. I presume there will be two choices: either convert strings
> automatically, or provide two different character & string types.

You need neither conversions nor two different types. Gauche uses
utf-8 in internal representation of strings, while ucs-4 to
represent individual characters, in favor of efficient FFI.
The cost is O(N) string-ref and string-set!, but these procedures
are, IMHO, not necessary in many cases if you have string ports
and string matching&extraction library.


From: John Cowan <cowan_at_ccil.org>
Subject: Re: [r6rs-discuss] perhaps i should be formal, but....
Date: Thu, 15 Mar 2007 00:09:56 -0400

> Alternatively, you can use a design in which strings that use the Latin-1
> repertoire are stored as Latin-1, strings that use the BMP repertoire
> are stored as UCS-2, and all others as UCS-4. That allows string-ref to
> be O(1) always, but string-set! winds up being O(N) in the general case,
> though still O(1) in most practical situations.

A bit of off-topic, but I'd like to point out that such "smart"
string implementation tends to have difficulty with preemptive
threads. Presumably such a string object has some indication of
the kind of representation, and a pointer to the actual string body.
What if one thread replaces the kind and a pointer (for "upgrading"
the string kind by string-set!) and another thread accesses it
inbetween?

This would lead to immutable strings, but it would be a topic of
R7RS or later, as Per Bothner said in other message, so I shut up now.

--shiro
Received on Thu Mar 15 2007 - 01:52:29 UTC