<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>I don't know if I would agree with the kind of thinking that Modula-3 needed CHAR and WIDECHAR for a JVM execution engine device, but for the interpretation function.<br>For instance what would be the purpose of handling more than 140 CHARS in a mobile phone, I don't see the need for that, or if you need to target many languages is useful but in a compiler setting not in an execution environment like CM J-V-M<br>For instance let's suppose you have a Win16 device and an IBM JVM ready hardware, would you need two types of char? Maybe but for efficiency reasons, not for anything more. I agree with WIDECHAR devices in the sense of a General purpose language is better than many language encodings but we need to see the devices for that, for instance mobile phones, etc. Normally JVM-ready phones.<br>Thanks in advance<br><br>--- El <b>lun, 2/7/12, Dragiša
 Durić <i><dragisha@m3w.org></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Dragiša Durić <dragisha@m3w.org><br>Asunto: Re: [M3devel] Simple change to WIDECHAR type<br>Para: "Tony Hosking" <hosking@cs.purdue.edu><br>CC: m3devel@elegosoft.com<br>Fecha: lunes, 2 de julio, 2012 03:09<br><br><div class="plainMail">To be compatible, at least partially, with some other solution.<br><br>Completeness of that other solution did not rub magically on cm3 just because they invented WIDECHAR as standard scalar type.<br><br>On Jul 2, 2012, at 3:34 AM, Tony Hosking wrote:<br><br>> As far as I know, WIDECHAR was simply for the CM3 JVM to support Java char which is 16-bit.<br>> <br>> On Jun 30, 2012, at 1:24 PM, Mika Nystrom wrote:<br>> <br>>> <br>>> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:<br>>> ...<br>>>> <br>>>>
 Solution:<br>>>> =3D=3D=3D=3D=3D=3D<br>>>> <br>>>> * Redefine WIDECHAR to hold at least 20 bit values, or create UNICHAR or =<br>>>> GLYPH (and leave WIDECHAR as it is for vertical compatibility) so we can =<br>>>> hold unencoded Unicode characters in scalar values in our Modula-3 =<br>>>> programs, while preserving their properties.<br>>>> * Implement properties, relations and methods defined for  Unicode. With =<br>>>> ASCII, numeric order is everything. With Unicode - it is not. This is =<br>>>> probably very big project but we can start somewhere, and let interested =<br>>>> parties build on it. Dirk Muysers did work in this regard already.<br>>>> * Whoever thinks we don't need this and our "tradition" and "legacy" are =<br>>>> important, please read this: =<br>>>> <a href="http://unicode.org/standard/WhatIsUnicode.html"
 target="_blank">http://unicode.org/standard/WhatIsUnicode.html</a> .<br>>>> <br>>>> dd<br>>> <br>>> Given what you have said about the near-uselessness of WIDECHAR, does anything<br>>> actually use it much?  What breaks if it is redefined to be the same as, say,<br>>> INTEGER?  (Or Word.T)<br>>> <br>>> CHAR is quite useful for processing 7-bit ASCII, and it would be lovely if<br>>> that could go back to using the SRC data structures.  For people who do stuff<br>>> like write VLSI design tools... (probably many other large-scale applications<br>>> would like it too).<br>>> <br>>>  Mika<br>> <br><br></div></blockquote></td></tr></table>