From ynk@ome Tue Nov 12 12:25:29 1991 Received: from mcsun.EU.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA22257; Tue, 12 Nov 91 12:25:29 +0100 Received: by mcsun.EU.net via EUnet; id AA22909 (5.65a/CWI-2.123); Tue, 12 Nov 1991 12:25:37 +0100 Received: by kddlab.kddlabs.co.jp (5.61/6.2Junet) id AA17793; Tue, 12 Nov 91 18:06:31 +0900 Received: by tis1.tis.toshiba.co.jp (3.2/6.4J.6-R47) id AA25154; Tue, 12 Nov 91 16:39:40 JST Return-Path: Message-Id: <9111120739.AA25154@tis1.tis.toshiba.co.jp> To: wg14@dkuug.dk, wg15rin@dkuug.dk Cc: x3j16-intl@redbone.att.com From: ynk@ome.toshiba.co.jp (Yasushi Nakahara) Subject: Re: (SC22WG14.142) is_wident() routine Date: Tue Nov 12 11:35:15 JST 1991 X-Charset: ASCII X-Char-Esc: 29 Keld, Thank you for posting information about is_wident() routine. : Date: Sat, 9 Nov 91 21:03:24 +0100 : From: Keld J|rn Simonsen : To: dkuug.dk!wg14 : Subject: (c.wg 568) (SC22WG14.142) is_wident() routine : Cc: dkuug.dk!wg15rin, redbone.att.com!x3j16-intl : : At the WG15 meeting I presented the WG14 decision from the may 1991 meeting : to have the extended character set support for identifiers : determined by the is_wident() function. Unfortunately, since at the WG15RIN (and WG15) meeting you just mentioned the "is_ident()" function, not the "is_wident()", other people except Japanese experts did not understand whether or not you were trying to solve the issues in a more generic way. : I requested that a new class be defined for POSIX locales, named : "ident" to support such functionality, also for POSIX languages such : as the shell. : : WG15RIN recognized the idea, but had further questions regarding : this, including if this was really the way WG14 wants to go, And if I remember correctly, the WG15RIN's concerns are the following. - Is a class of "identifiers" common to all computer languages? Each computer language may have its own class for identifiers. - Is the existing class of "alpha" insufficient for such usage? - Is a dynamic definable/switchable class for identifiers good enough from a security point of view? : as they have not seen any specification of the is_wident() function. : I would thus encourage the Japanese to include a definition : of is_wident() in the MSE proposal. Again, what I suggested at the meeting was that a generic functionality such as a currently proposed function is_wctype(wc, set_wctype("xxxx")) in the MSE should be introduced first (rather than inventing a new is_xxxx() function as yet another patch work!), and then a specific function such as the is_wident (NOT is_ident) may (or may not) be defined on top of the is_wctype functionality with a certain consensus among the community like the WG14 or SC22 which community (of computer language) should be willing to use such a new character class (for its lexical analysis). Particularly in the POSIX environment, we should discuss how to specify the is_wctype functionality in the localedef stuff. Please remember a bad example and a history of "termcap" and/or "terminfo" database approach to achieve a kind of xxxx independency, where each vender tried to introduce his/her own termcap/terminfo entry without consensus among the industry, and in particular without a generic mechanism of "user/vender definable capability". His/her effort just introduced yet another unnecessary chaos in the community, I observe. Note that I'm not saying that the termcap/terminfo approach was wrong. Rather, I strongly support the idea of termcap/terminfo, which enable programs be more xxxx independent. However, without some smart mechanism to introduce a user/vender definable capability, the advantage of such good idea never meet various requirements in a compatible and portable way. : WG15 will ask WG20 (i18n) how to handle this generally for : programming languages. There are resolution and liaison : statements regarding this, which I will forward to WG14 when available : electronically. As a member of the WG15 Drafting Committee, I will post the liaison statement in anther email, soon. Yasushi Nakahara TOSHIBA Corp. Phone: +81 428-32-0722 Fax: +81 428-32-0408 Email: ynk@ome.toshiba.co.jp | y.nakahara@ui.org | y.nakahara@xopen.co.uk | ..!tsbome!ynk