<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>string class is  a super-set by definition of CHARs scripts, note TEXT a primitive type, so it can have every string characteristics. Thus we don't need any other non-primitive TEXT types<br>The need for other TEXT isn't a matter, as it can add or have any characters but put burden of choice to the implementation.<br>WIDECHARs aren't at all needed by Modula-3 at all, but to keep copying CHARs in other is not in my view more string formats is the real advantage to speed up implementation to get two CHARs strings.<br>So I agree in that we must look the performance burden in citing implementations,<br>for instance keep compatibility without loosing special performance.<br>My view is that we need to re implement that in m3core, in either C, for instance or some safe subset of Modula-3 to speed up a little, for instance DEC-SRC, etc, or a subset of
 SPIN-M3 (somethings I like).<br>But this is more stuff to do, fun certainly, but I would want to concentrate in supporting either that by OS definition, or by accessing hardware (who cares using C RT for Linux, but if we can be faster let's do it in whatever it takes).<br>In the end we can provide better interfaces to develop current OS than they provide to us, so what then it matters if we offer some code to Linux if at all, interested.<br>Greg Nelson told that Rd/Wr are a very nice piece of string type unappreciated by most of the current mainstream languages. <br>Thanks in advance<br>Thanks in advance<br><br> <br><br>--- El <b>jue, 28/6/12, Rodney M. Bates <i><rodney_bates@lcwb.coop></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Rodney M. Bates <rodney_bates@lcwb.coop><br>Asunto: Re: [M3devel] UTF-8 TEXT<br>Para: m3devel@elegosoft.com<br>Fecha: jueves,
 28 de junio, 2012 09:10<br><br><div class="plainMail"><br><br>On 06/28/2012 07:44 AM, Hendrik Boom wrote:<br>> On Wed, Jun 27, 2012 at 02:20:41PM -0500, Rodney M. Bates wrote:<br>>><br>>> Text is highly general and easy to use.  Concatentations and substrings<br>>> are easy.  Semantics, to its clients, are value semantics, similar to INTEGER.<br>>> Random access by *character* number is easy and, hopefully, implemented<br>>> with efficiency at least better than O(n).<br>><br>> Does it have to be a *character* number we use to index a string?  I<br>> don't know of any situations where that aspect is importnat enough<br>> to force everyone to waste storage on it.<br>><br>> -- hendrik<br>><br><br>It is absolutely essential that it be a character, if you care about<br>Text being a meaningful abstraction.  A byte index is a very low level<br>view, now that we have a variable-length
 encoding, and *especially*<br>now that there are multiple possible ways of representing strings.<br>strings.<br><br>When it was only ASCII (or ISO-latin1), it was a character<br>index, and the abstraction was there.  The fact that it was also a<br>byte index is a coincidental consequence of the choice of underlying<br>physical representation.  Now we have a much messier situation regarding<br>representations, but we should not destroy the abstraction and force<br>everyone to always get down into the bowels of the different representations.<br><br>There will still be mechanisms for low-level coding if you have some<br>compelling reason, or just don't want to rewrite something existing.<br>But let's protect the option of dealing with characters with the same<br>abstraction we have had in the past.<br></div></blockquote></td></tr></table>