From ynk@ome Tue Nov 12 12:29:17 1991 Received: from mcsun.EU.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA22381; Tue, 12 Nov 91 12:29:17 +0100 Received: by mcsun.EU.net via EUnet; id AA23102 (5.65a/CWI-2.123); Tue, 12 Nov 1991 12:29:28 +0100 Received: by kddlab.kddlabs.co.jp (5.61/6.2Junet) id AA17858; Tue, 12 Nov 91 18:07:02 +0900 Received: by tis1.tis.toshiba.co.jp (3.2/6.4J.6-R47) id AA25198; Tue, 12 Nov 91 16:39:58 JST Return-Path: Message-Id: <9111120739.AA25198@tis1.tis.toshiba.co.jp> To: wg15@dkuug.dk, wg14@dkuug.dk Cc: x3j16-intl@redbone.att.com From: ynk@ome.toshiba.co.jp (Yasushi Nakahara) Subject: SC22/WG15 N229R: WG15 Liaison Statement to WG20 on is_ident issue Date: Tue Nov 12 13:25:44 JST 1991 X-Charset: ASCII X-Char-Esc: 29 Hi concerned experts, As requested by Keld Simonsen, I'm sending the SC22/WG15 N229R; SC22/WG15 liaison statement to SC22/WG20 on is_ident issue, as well as the related Resolution in the WG15 Kista meeting on November 5 - 8, 1991 in Stockholm. For those who may receive the duplicated copy of N229R, please accept my apologies. 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 p.s. Keld, Regarding the WG15 circulation, I'm sending this to wg15@dkuug.dk rather than wg15rin@dkuug.dk. So, if some people in WG15RIN are missing in the SC22WG15 mailing list, please forward this to such people. Thank you in advance. ========================== SC22/WG15 Resolution 179 ========================== Resolution 179. ISO/IEC JTC1/SC22/WG20 Liaison Whereas it is desirable that programming languages allow the use in identifier names of a richer alphabet than that defined by the Invariant Subset of ISO 646, and Whereas it is desirable that programming languages agree on the classes into which characters may be divided, and Whereas ISO/IEC CD 9945-2.2 defines several utilities with input statements syntaxes that approach the complexity of formal programming languages, and Whereas a general solution to these problems is preferred to solutions specific to ISO/IEC 9945-2 utilities, Therefore, ISO/IEC JTC1/SC22/WG15 requests that ISO/IEC JTC1/SC22/WG20 review, comment and take appropriate action on ISO/IEC JTC1/SC22/WG15 N229R. ===================================== Action 13: ISO/IEC JTC1/SC22/WG15 liaison to ISO/IEC JTC1/SC22/WG20 to forward to ISO/IEC JTC1/SC22/WG20 the ISO/IEC JTC1/SC22/WG15 Liaison Statement WG15 N229R ========================== SC22/WG15 N229R =================================== SC22/WG15 N229R November 7, 1991 Title: Liaison statement from WG15 to WG20 on character class and identifier member character issues Source: JTC1/SC22/WG15 __N231__ (Kista WG15 resolutions) Project: (9945-2 project) Status: Liaison statement in response to SC22/WG15RIN N042 Distribution: WG20 Requested action: For review and comment ISO/IEC JTC1/SC22/WG15 November 7, 1991 Title: Liaison statement from WG15 to WG20 on character class and identifier member character issues Source: JTC1/SC22/WG15 __N231__ (Kista WG15 resolutions) Pursuant to our previously established liaison, ISO/IEC JTC1/SC22/WG15 would like to bring the following issues to the attention of ISO/IEC JTC1/SC22/WG20, and requests that ISO/IEC JTC1/SC22/WG20 consider further investigation of these matters. 1. Character classes 1.1 Background JTC1/SC22/WG14, JTC1/SC22/WG15, and JTC1/SC22/WG21 are addressing the issue of dividing character sets into classes (alphabetic, numeric, whitespace etc.). Internationalization considerations require that the membership of such classes can be varied according to the execution locale. In its recent work, JTC1/SC22/WG15RIN (the rapporteur group on internationalization) has determined that there may be a need for a new class, that of characters which may appear in programming language identifiers (e.g. variable names). There may well be further such classes identified by other groups. 1.2 Issues for resolution a. Bearing in mind the requirements of internationalization, what minimum set of character classes is appropriate for implementation in programming languages? b. Does this minimum set include a class of characters which may appear in identifiers, as distinct from alphabetic (see also item 2, below)? c. Is it desirable that programming languages provide the ability to define new classes or change the contents of predefined classes at translation or execution time? 2. Extended alphabets in identifiers 2.1 Background In locales having larger alphabets than that provided by ISO 646, it may be desirable to permit the inclusion of characters from those larger alphabets in identifiers. For example, accented letters from such larger alphabets might be included in identifiers. 2.2 Issues for resolution a. How may this best be achieved, given that any solution should: (1) not unnecessarily compromise source program portability or system security, (2) be applicable to all types of translation system (for example, both compilers and interpreters), (3) be applicable to a wide range of national requirements? (4) recognize that the class of nonalphabetic characters acceptable in identifiers vary across programming languages (e.g., the hyphen is acceptable in COBOL identifiers, but not in Fortran) and in various positions within the identifiers (e.g., digits and underscores are generally not acceptable in the first position). b. Is the concept of a class of characters (one distinct from class "alpha") which may appear in identifiers useful in this connection? =============================================================================== EOF