[M3devel] Simple change to WIDECHAR type

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Mon Jul 2 17:27:56 CEST 2012


Hi all:
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.
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
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.
Thanks in advance

--- El lun, 2/7/12, Dragiša Durić <dragisha at m3w.org> escribió:

De: Dragiša Durić <dragisha at m3w.org>
Asunto: Re: [M3devel] Simple change to WIDECHAR type
Para: "Tony Hosking" <hosking at cs.purdue.edu>
CC: m3devel at elegosoft.com
Fecha: lunes, 2 de julio, 2012 03:09

To be compatible, at least partially, with some other solution.

Completeness of that other solution did not rub magically on cm3 just because they invented WIDECHAR as standard scalar type.

On Jul 2, 2012, at 3:34 AM, Tony Hosking wrote:

> As far as I know, WIDECHAR was simply for the CM3 JVM to support Java char which is 16-bit.
> 
> On Jun 30, 2012, at 1:24 PM, Mika Nystrom wrote:
> 
>> 
>> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:
>> ...
>>> 
>>> Solution:
>>> =3D=3D=3D=3D=3D=3D
>>> 
>>> * Redefine WIDECHAR to hold at least 20 bit values, or create UNICHAR or =
>>> GLYPH (and leave WIDECHAR as it is for vertical compatibility) so we can =
>>> hold unencoded Unicode characters in scalar values in our Modula-3 =
>>> programs, while preserving their properties.
>>> * Implement properties, relations and methods defined for  Unicode. With =
>>> ASCII, numeric order is everything. With Unicode - it is not. This is =
>>> probably very big project but we can start somewhere, and let interested =
>>> parties build on it. Dirk Muysers did work in this regard already.
>>> * Whoever thinks we don't need this and our "tradition" and "legacy" are =
>>> important, please read this: =
>>> http://unicode.org/standard/WhatIsUnicode.html .
>>> 
>>> dd
>> 
>> Given what you have said about the near-uselessness of WIDECHAR, does anything
>> actually use it much?  What breaks if it is redefined to be the same as, say,
>> INTEGER?  (Or Word.T)
>> 
>> CHAR is quite useful for processing 7-bit ASCII, and it would be lovely if
>> that could go back to using the SRC data structures.  For people who do stuff
>> like write VLSI design tools... (probably many other large-scale applications
>> would like it too).
>> 
>>  Mika
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120702/16e81d8d/attachment-0002.html>


More information about the M3devel mailing list