From Miles.Ellis@etrc.ox.ac.uk Thu Jan 23 18:12:58 1997 Received: from oxmail4.ox.ac.uk (oxmail4.ox.ac.uk [163.1.2.33]) by dkuug.dk (8.6.12/8.6.12) with SMTP id SAA10548 for ; Thu, 23 Jan 1997 18:12:53 +0100 Received: from ermine.ox.ac.uk by oxmail4 with SMTP (PP) with ESMTP; Thu, 23 Jan 1997 17:08:10 +0000 Received: from [163.1.85.1] (com1.etrc.ox.ac.uk [163.1.85.1]) by ermine.ox.ac.uk (1.1/8.8.3) with ESMTP id RAA30020 for ; Thu, 23 Jan 1997 17:09:00 GMT X-Sender: mellis@ermine.ox.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Jan 1997 17:12:25 +0000 To: sc22wg5 From: Miles Ellis Subject: Internationalization in Fortran As you will know from the timetable attached to the agenda for Las Vegas, the Convenor of WG20 (Internationalization), Arnold Winkler, is giving a tutorial on Monday morning. He will also be joing the MISC subgroup that afternoon and, if it would be helpful, on Tuesday. Internationalization (or i18n as it is usually referred to for obvious reasons) is not a topic which has concerned Fortran very much, despite its growing importance in some other areas. However, it is very clear that it is becoming a topic of major importance in the eyes of JTC1 and SC22 and that a language's approach to i18n issues will be treated very seriously during CD and DIS ballots in future years. [For those who have no idea what I am talking about, at its simplest i18n provides the ability for an application program to adapt itself to the cultural environment in which it is being used. For example, in most European countries a comma is used as a decimal point and not a period (full stop), as in the UK and USA. An internationalised program would display a comma or a period as appropriate WITHOUT THE PROGRAM BEING CHANGED IN ANY WAY. This is a fairly trivial example, but it will suffice for now.] I believe that it is essential that Fortran 2000 has the ability to deal with at least a subset of the i18n issues that WG20 has identified in its Technical Report on this subject. I also believe that it is possible that most of these, at least in the F2000 timeframe, may be provided by the use of calls to special procedures within the operating system. One of the tasks of the MISC subgroup will be to decide what, if anything, should be added to F2000 to make i18n feasible, other than the ability to call C procedures - which should deal with the operating system calls. By the same token, I believe that the proposed TR on interoperability which, may I remind everyone, is by definition intended to incorporated in Fortran 2000, is of particular importance in dealing with the whole subject of i18n. So even if you haven't worried too much about interoperability with C, perhaps you should in order to ensure that Fortran is compatible with SC22's requirement that all languages provide suitable i18n facilities. Equally, it might be worth thinking about any particular cultural issues in your country which might/do affect computer input and output (since it is the human interface that we are talking about), so that you can raise them with Arnold while we have him with us. Miles Ellis WG5 Convenor Email: Miles.Ellis@etrc.ox.ac.uk Phone: +44 1865 270528 Fax: +44 1865 270527