From Jerry@Wagener.com Mon May 4 16:30:15 1998 Received: from mail.ionet.net (mail.ionet.net [206.41.128.22]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id QAA10356 for ; Mon, 4 May 1998 16:30:11 +0200 Received: from [207.204.105.59] (tulnas6-47.ionet.net [207.204.105.59]) by mail.ionet.net (8.8.5/8.7.3) with ESMTP id JAA07899 for ; Mon, 4 May 1998 09:30:56 -0500 (CDT) X-Sender: jwagener@ionet.net Message-Id: In-Reply-To: <199804301205.OAA07024@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 May 1998 09:32:30 -0500 To: sc22wg5@dkuug.dk From: Jerry Wagener Subject: Re: (SC22WG5.1500) Internationalization in Fortran On 98-04-30 Miles Ellis wrote: >I have just received a copy of ISO/IEC TR 11017:1998 (Framework for >internationalization), which was prepared by WG20 as a guide for other WGs. >The TR describes the type of features that might be provided in languages >in order to provide i18n facilities. There are, however, only two examples >in the whole report of actual example code - both in Fortran! > >The first example shows how i18n features could be accessed from a Fortran >program by the addition of three intrinsic procedures: > >CULTURAL_ENVIRONMENT > which returns a processor-dependent code for the cultural environment > specified as an argument > >REPERTOIRE_KIND > which returns the kind type of the character repertoire associated with > the current cultural environment > >SET_ENVIRONMENT > which changes the current cultural environment > >A "cultural environment" is essentially a language-independent "locale" for >those familiar with C and POSIX. Once the environment and, if necessary, >the character set had been specified then it is assumed that the processor >would take care of a range of culturally sensitive issues (such as whether >to use a period or a comma as a decimal delimiter, for example). > >The second example is a sample module which shows how a Fortran program >having access to the above three procedures (and their underlying model) >might implement culturally sensitive sorting using overloaded relational >operators. This assumes the existence of two further intrinsic procedures >which provide the functions for generating keys and comparing strings >described elswhere in the TR, and which are based on the Canadian Standard >for ordering words in a culturally sensitive manner. > >I would recommend that anyone interested in this topic should get hold of a >copy of this TR. In particular, it might be useful for the J3 subgroup >developing i18n features for F2000. > >Miles > >Miles Ellis >Convenor: ISO/IEC JTC1/SC22/WG5 (Fortran) > >Email: Miles.Ellis@etrc.ox.ac.uk >Phone: +44 1865 270528 Fax: +44 1865 270527 ======================================================================== A "for what it's worth" comment inspired by the above note: ----------------------------------------------------------- A possibly "more fleshed-out" model that might be useful for this Fortran requirement is Java's support in the area of internationalization. I am not intimately familiar with the WG20 recommendations, but it appears that the Java implementations are, in some respects at least, consistent with Miles' description above. Certainly Java is the most "internationally-aware" computer language that I have ever used. For example it's character set is unicode, so it accommodates all (well, many) natural languages. More to the point, it has three "intrinsic" classes, Locale, NumberFormat, and DateFormat, that provide locale-specific formatting of numbers and dates. Each Locale object has country and natural language components; each NumberFormat object stores information needed to correctly format numeric values as numbers, percentages, or currencies for a given Locale; each DateFormat object stores information needed to produce dates and times in locale-specific formats. An (overloaded) intrinsic function (named "format") returns the correctly formatted string given a NumericFormat object and either a real or integer numeric value, or given a DateFormat object and a Date object (similar to what the Fortran 95 Date_and_Time intrinsic returns). These three classes make for a fairly clean, easy-to-use facility, but the same functionality could be achieved with a single (overloaded) character function that has three arguments: a numeric value (or date/time array), a country-ID and, for numeric values, some sort of indication as to whether the formatting is for numbers, percentages, or currencies. The Java implementation uses classes probably partially for the following reasons: Locales can be specified by either the ISO 2-character or 3-character country codes (I hadn't known about the 3-character code), NumberFormats can be further constrained with specified maximum and minimum number of integer and fraction digits, and the DateFormat class provides for format leniency (I don't know what that is). This additional functionality can also be achieved by adding (many) more arguments to the single function mentioned above (or by adding more intrinsic procedures, as Miles notes above), though I would be tempted to investigate using a couple of derived types and associated procedures, or even the new F2000 O-O type/class mechanisms - these sound like the right tools for this job. These Java classes can be seen in any reference on the Java API, including online at http://java.sun.com/products/jdk/1.1/docs/api/packages.html Jerry