From: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
