brainerd@unmvax.unm.edu (Walt Brainerd) (08/31/89)
Some comments posted to memebers of X3J3 that might be of interest regarding the use of square brackets in Fortran. First, from Gerhard Schmitt, official WG5 representative member of X3J3: As one of this "few" Europeans I like to explain the square bracket problem in more detail and correct some misunderstandings. I will comment on Bill Long's observations. But first of all I should explain the situation. After using 5 or 6 bit to represent a single character most vendors and standardizations bodies started in the end of the 70's to use 7 bit representations. This method was used very frequently outside the IBM world. During the last few years a new set of coding standards were developed using 8 bits. Because of more than 300 different charactes used in languages written with the latin alphabet it is necessary to extend the code (e.g. with escape sequenzes) or to limit the used characters. In the 7 bit code (allowes 96 "printable" characters and 32 "control" characters) there are a number of different character sets all based on ISO 646. One of this is ANSI X3.9 (ASCII). They all have the digits, the letters, and some special characters in common. But there are about 10 character possitions for "national" use. For example at the position of the dollar sign in the ASCII code is a pound sign in the Brithish standard. > 1) > One of the previous mail messages contained this reasoning for not using [] > as an alternate syntax: > > " So F8X couldn't use them, even > as alternate syntax because using such a keyboard, the Europeans couldn't > create a standard-conforming program that read any F8X standard-conforming > program. " > > The last part of this sentence is unclear to me. Is it necessary that a > Fortran program be able to read any other standard conforming program?? > I thought the COMPILER had to read the standard conforming program. And > compilers are usually written in C, Pascal, or some low level language, all > which understand []. You are right, even if it might be nice to READ in a [] it is not necessary. But the problem is not so simple. If a processor (this includes in Fortran the terminal and the communication lines as well as the compiler) supports only 7 bit characters you must make a decission to have [] or national characters (e.g. Umlaut). You may easely think about an environment with this constraints. If you have chosen to use national characters (e.g. to write names correctly) you can not have a standard conforming Fortran processor. More than that you also can not have a standard conforming C or Pascal processor. The reason is: to have a standard conforming processor this processor must accept [] but there is no means to do this. Using a different character (with the same code as []) to represent [] is not standard conforming as the Fortran standard is writen now. > 2) > The main issue which is continually avoided is how Europeans write C and Pas > programs, use VMS, or use a host of other software that use [] as part of th > syntax. One writer aptly pointed out that []-filled Pascal was invented in > Europe. Surely our friends across the atlantic are not that far removed from > the 20th century. I know some of them first hand. They write programs in C a > use VMS on their VAXen just like the rest of us. They HAVE [] on their > keyboards. Does not, indeed, this same ISO organization accept standards for > and Pascal that include the [] characters? The problem is not that VMS has no [] but that you can not have [] and national characters at the same time (if you use 7 bit codes). Usualy in a technical environment they use ASCII keyboards so the problem is that your friends have problems in writing papers in their own languages but have no problems in writing C and Pascal programs. See for example the clumsy method used by TeX to allow Umlaut. > The situation is becoming clearer day-by-day. The keyboards this fuss is ove > must be extremely rare and certainly obsolete. The committee has taken a st > on obsolete input equipment already: by adding the > < characters and allowi > >80 columns, the constraints of the old IBM 026 keypunch have been rejected. > Shouldn't you be consistent, and also ignore the constraints imposed by > obsolete euro-keyboards? As you might count on your own keyboard (it has 48 keys for caracters - has it? - and this gives 2*48=96 characters) this is not only a problem of the keyboard but may be solved by having more than two layers. It is also a problem of telecommunication lines to support 8 bit characters. > This is not an issue of what is best for the standard (clearly [] is better > than (/ /)), but rather a case of petty assertiveness on the part of some > Europeans. If WG5 continues to take this position seriously, > the ANSI committee should seriously consider removing WG5 from participation > the standards process. As a member of WG5 I would better not comment this statement. But in the case that ANSI delays the developement of the standard (first scheduled for mid 80's) further it might be better that WG5 consider removing ANSI from its international responsibility. Nevertheless if we are talking about a Fortran standard to be published in 5 years or later I would accept any requirement for 8 bit characters. > How's them for fight'n words! In all seriousness, I am continually assaulte > by adherents of "modern" languages with comments like "isn't Fortran dead y > and "Fortran is a terrible language". We have a serious image problem with > those in the Computer Science department, the people who now train and cemen > the biases for all future generations of programmers. My usual defense is > "many of the dumber restrictions are no longer enforced in actual > implementations" and especially, "wait until you see Fortran 8X!" How do yo > expect computer scientists to take us seriously if we drop a syntax containi > [] because those characters are not available on keyboards! They wouldn't ev > believe the excuse. Do we really want to set ourselves up to public ridicule > just to pacify the egos of a few Europeans desperately clinging to an obsole > past? It is not this few Europeans - the EC market is at least the same size then the US market. Some say that the EC market is greater than the US. But it is not a question of size, it is a question of quality of computer usage. If you look on the real usage of computers in the technical environment (where Fortran is mostly used) you can see a change during the last years. Computers (eccept of a "few" supercomputers) are not longer only used for calculation but also for supporting all parts of our work. This includes all forms of text processing. Creating the requirement for national characters. The true solution to this ate systems supporting larger character sets (8 bit characters, multi-octet characters). Unfortunately there is a large investment in 7 bit systems - many of them using "national" characters. Adding [] into Fortran will seriously heart all of this users. I could understand your problem. but I see no different solution under this circumstances. Regards, Gerhard ------------------------------------------------------------------ And from Lawrie Schoenfelder, X3J3 member: I have been known to use the same arguments myself in past discussions within X3J3, but as an English speaking European I was not as well aware of the nature of the problem. It is not so much a problem of obsolete terminals (IBM in the USA has a problem with [] still) it is that the only international standard for character coding with widespread implementation is ISO 646. This is essentially ASCII with a number of the code-points reserved as national use characters. ([] are in that catagory) These may and frequently are used for accented characters in countries where English is not the native language. It would not improve the readability of Fortran programs to have array constructors bounded by c cedila and e grave. This problem has caused very considerable difficulty in the standardisation processes involved at ISO level with C and Pascal. More importantly the fact that C and Pascal do use [] has caused very significant practical portability portability problems for programs moving between countries; something that is becoming very common now in Europe. Fortran up to now has avoided these problems by sticking to a conservative and universally available subset of the characters when constructing its source code. (Of course F8x went and skrewed up totally at its last meeting with "processor determined, somehow but I'm not telling how, user specified" source code character sets, but this was surely an aberation) I should also point out that ANSI is drafting the ISO standard revision for Fortran under delegation from the relevent ISO committee. WG5 is the ISO working group directing the technical work for ISO. ANSI could cock-a-snook at ISO by telling WG5 to get lost, but it would find it was producing only an USA standard and the rest of the world might just take something of a dim view of such behaviour! The result could be a different US standard from the ISO one As I say I have been convinced by my European colleagues that the problem is real and have changed my position on the committee as a result. (/ /) is not pretty but it is portable. [] is pretty but it sure as hell isn't portable. Sad but such is life. -- Walt Brainerd Unicomp, Inc. brainerd@unmvax.cs.unm.edu 2002 Quail Run Dr. NE Albuquerque, NM 87122 505/275-0800