Subject: Re: (i18n 73) Re: paper presented to WG11 (#20)

From: [email-masked] (Matt.Caprile)
Date: Mon, 18 Feb 91 18:47:05 MET

I gess I missed some of the discussion, since I can't find the mail
that Kim refers to. But (as usual) that won't stop me from making
some comments. The mail in question is:

* Subject: (i18n 73) Re: paper presented to WG11 (#20)
* Date: 13 Feb 91 12:04:38 MET (Wed)
* From: [email-masked] (Kim F. Storm)
* Cc: [email-masked]
* 
* I agree with Keld that using the names in the charmap is an excellent
* way to write portable strings (provided we can agree on the character
* names to use in the charmap).
* 
* The problem with introducing these general strings is how to merge
* them into existing languages and utilities.  Keld uses the example
* 
*            "s<o/>ndag"
* 
* which would need some currently unspecified functions to interpret
* (e.g. for printing or pattern matching).
* 
* Let us take this a step further and play with the idea of using the
* following syntax in C:
* 
* 	char *str = "s\<o/>ndag";
 [...]
* 	3. Compile the \< token into an otherwise unused character
* 	   code and use that at run-time to trigger "on the fly"
* 	   substitution in all STANDARD routines operating on strings,
* 	   e.g. strcpy and printf.
* 
* 	4. Forget the whole thing, and write a complete new set of
* 	   functions to operate on "portable strings".
* 	   
* as long as it works...), I would prefer solution #3.

Any reason not to define the above ideas in the wchar_t functions that
the ISO C working group is coming out with ? It seems that it would be
rather trivial to "reserve" the escape mechanism to define the references
to the symbolic names found in the charmap file. Then just define the
strings as  (wchar_t *)  and specify that the compiler do whatever
is necessary so that it will be interpreted at run-time, not at
compile time.

This has several advantages:
 1- new feature is associated with new functions/data types. You don't
    have to worry about breaking existing programs.
 2- Using the wchar_t type for what it was designed for : portable
    international applications, indepedant of encoded character set
    and the size of the representation of characters in the codeset.
 3- This will encourage programmers to use these new functionalities,
    thus increasing the number of internationalised (or intl-able)
    applications.

Am I missing something here ? It can't REALLY be that easy.

matt.
---------------------------------------------------------------------------
----   Matt Caprile	  phone : +33 7639 7752   fax: +33 7639 7518   ----
----   [email-masked]       -or-         m.caprile@xopen   ----