<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>making changes of type representation of TEXT in text makes no sense, it's a violation of the Text abstraction<br>http://books.google.com.co/books?id=FbemcUFa0JIC&pg=PA303&dq=source=bl&ots=POGbXUhcW1&sig=WULSpZ74yYU30s-cZ2zhtNTByd8&hl=en&redir_esc=y#v=onepage&q&f=false<br><br>you are in fact claiming that the default type of CHAR is Latin-1, I don't get that because you type extend CHAR and say it's not default, there is something bad, I'm some how suspicious about this need to type in *different* two ranges for receiving a character in one type script and one in another, essentially meaning that the language is wrong in declaring TEXT as a opaque type and should use both kind of strings always or worse the non-default type, which is naturally impossible.<br>Sorry guys, but I'm not agreeing with you in this one, I hope
 you make the best of CM3 work or leave alone the package a la DEC-SRC.<br>If you are thinking in widening the TEXT string package make it polymorphic it doesn't add complexity burden to the language, it explains better the CHAR type and its extension but do it naturally using the language types, don't create your own one with only that purpose.<br>THanks  in advance<br> <br><br><br><br>--- El <b>sáb, 14/7/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] AND (…, 16_ff)… Not serious - or so I hope!<br>Para: m3devel@elegosoft.com<br>Fecha: sábado, 14 de julio, 2012 15:05<br><br><div class="plainMail"><br><br>On 06/27/2012 02:58 AM, Dirk Muysers wrote:<br>> Some time ago I have started to develop a unicode library based<br>> on the
 old M3 text model but using UTF-8 internally rather than<br>> Latin-1 (see README attachement). For reasons best known to<br>> me I had to put it on the backburner in favour of more urgent work.<br>> If anybody is interested in furthering this solution I would eagerly<br>> give the existing (pre-alpha) code away.<br>> This being said, there are certainly better hash algorithms than the<br>> one used by m3core (eg Goullburn, see<br>> <a href="http://www.clockandflame.com/media/Goulburn06.pdf" target="_blank">http://www.clockandflame.com/media/Goulburn06.pdf</a>).<br>><br>><br>And:<br><br><br>1. Properties<br><br>This part deals with properties of Unicode code-points/characters. We call Unicode code-points "runes" for brevity.<br>Unlike WIDECHAR's, runes cover the the whole gamut of the Unicode specification. We could have defined a Rune as<br>TYPE Rune = [0..16_10FFFF], but  unfortunately not all values in the code-point
 range are valid and others are left<br>undefined, so a "Rune" is defined as an integer. The library uses defensive programming by not allowing a string to<br>contain any invalid or undefined Rune.<br><br>I don't understand the reasoning here.  Your criticism of the subrange type is that it contains invalid values<br>between the bounds, which you address with dynamic value checks inside the library code.  But why eliminate the<br>subrange and changing the type to an integer?  It only drastically increases the number of invalid values,<br>by a factor of over 2^11 times, if integer is 32-bit, otherwise more.  And it demotes the status of these<br>from statically-detected, in one compile, to dynamically-detected, requiring massive testing to get an even<br>partial level of confidence.  It also precludes storing them in less than 64 bits on a 64-bit machine.<br><br>Am I missing something?<br></div></blockquote></td></tr></table>