[bitc-dev] String encoding, again

[Ben Kloosterman]

Allows string to be programmer friendly  and Ustring for indexing
performance. Why define the views ? Some string implementations may not
support direct indexing ie only vs higher levels  or is GetUString8()  ,
GetUString16() or GetUString32() regarded as a view ?

 

Question why not define Ustring as a vector /array ? This makes it clear
that 

 

String should wrap or at least support Ustring

The vector is used for interop  

 

Ben

 

From: bitc-dev-bounces at coyotos.org [mailto:bitc-dev-bounces at coyotos.org] On
Behalf Of Jonathan S. Shapiro
Sent: Thursday, March 24, 2011 1:20 PM
To: Discussions about the BitC language
Subject: Re: [bitc-dev] String encoding, again

 

In the interest of progress, I am going to concede defeat on the problem of
strings. In the interest of progress, I propose to adopt the following
position:

*	Instances of the BitC type String contains a sequence of Unicode
code points. This is a well-formedness constraint, and it is a requirement
that all string manipulation functions maintain it.
*	The internal encoding of a String is unspecified, but will be
selected by the implementation to optimize for space.
*	Indexing operations on Strings operate in no worse than linear time.
*	Indexing operations will be provided on Strings providing views
corresponding to ucs1, ucs2, and ucs4 code units.
*	Instances of the BitC type UString likewise contain a sequence of
Unicode code points.
*	A UString is indexed only on code points.
*	A UString is required to provide constant-time indexing on code
points.

Violent objections?


shap

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20110324/dafc7d8d/attachment-0001.html