From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d7340a24f4e8fef1,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-14 16:25:12 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!wn11feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail From: David Starner Subject: AI-285 - Comment from Unicode list User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity. (Debian GNU/Linux)) Message-Id: Newsgroups: comp.lang.ada MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Sun, 15 Feb 2004 00:25:11 GMT NNTP-Posting-Host: 12.72.69.145 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1076804711 12.72.69.145 (Sun, 15 Feb 2004 00:25:11 GMT) NNTP-Posting-Date: Sun, 15 Feb 2004 00:25:11 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:5576 Date: 2004-02-15T00:25:11+00:00 List-Id: Markus Scherer writes (at *** D. Starner wrote: >> #12 UTF-16 for Processing > > This is incorrect in saying that Ada uses UTF-16. It supports UCS-2 > only. The text of the standard says: > > The predefined type Wide_Character is a character type whose values > correspond to the 65536 code positions of the ISO 10646 Basic > Multilingual Plane (BMP). [...] > > which doesn't include surrogate code points. The next True, but not much different/worse than for Java, for example. Once you have 16-bit types and string literals, adding a few functions to deal with supplementary code points is not hard. We did this for Java in ICU4J. There is little difference for a language between supporting UCS-2 or UTF-16 because where functions do not handle supplementary code points, they usually also don't handle Unicode versions above 3.0 - so string case mappings etc. are the same. A language like that can be relatively easily upgraded to full UTF-16 handling by updating the character and string function implementations, and adding a few new APIs - that is what Java is doing. The upgrade is done naturally when the standard functions are extended to Unicode 3.1 or later. As such, whether the strings contain UCS-2 or UTF-16 depends less on the language definition and more on the functions that are used, and the version of the standard libraries. > version of Ada will have 32-bit characters to fully > support Unicode - the text of the proposal is here: > > > > plus lengthy discussion on the issues. Thank you very much for the link. The proposal seems to be to continue to treat Wide strings as UCS-2, and to treat Wide_Wide strings (a new type) as UTF-32. This would give Ada a total of three different native string types on the language level. It would also mean that existing code, using 16-bit strings, would not benefit from an upgrade but would instead have to be rewritten for support of supplementary code points. This may in fact slow down such support. There will be a presentation of the choices for Java (including UTF-32) at IUC 25. Best regards, markus ***