Hello, "Han-Wen Nienhuys" <[EMAIL PROTECTED]> writes:
> On Mon, Jun 9, 2008 at 3:10 PM, Neil Jerram <[EMAIL PROTECTED]> wrote: >> Guile's string API is aiming not to be 8-bit-assuming, and I would >> guess from the code above that the C++ string class is 8-bit-assuming. > > Sorry, I guess I don't understand. What _is_the assumption for > representing strings in GUILE? Strings in Guile will eventually be sequences of Unicode code points (as opposed to "bytes"), which can be represented in a variety of different ways (UTF-8, UCS-4, etc.). How Guile represents strings and whether this representation "changes dynamically" (as you suggested) should not be exposed to the applications in order to leave as much freedom as possible to Guile's implementation strategy. Instead, applications should be written against an encoding-oblivious API. This is what core R5RS constructs and SRFI-1[34] provide at the Scheme level. Thanks, Ludovic.
