corbett@beatnix.UUCP (Bob Corbett) (06/27/89)
When I asked why tabs were not included in the draft standard, Bill
Leonard replied
Well, one reason is that we can't get a majority
to agree on what a tab would mean.
That is exactly why tabs should be included in the standard. I have yet
to see a FORTRAN compiler that did not allow tabs in at least some contexts,
and I have yet to see two FORTRAN compilers written by different authors
that treated tabs the same. Most users do not know or do not care that tabs
are nonstandard, and liberally sprinkle their codes with them.
Consider the case of tabs in character literals. I know of no recent
compilers that do not allow tabs in character literals. However,
the interpretation of those tabs varies considerably. I have seen compilers
implement all of the following interpretations:
1. Tabs are treated as single characters both in the source
line and in the character value. This interpretation is
the most common.
2. Tabs are treated as single characters in the character value
but as an advance to the next tab stop in the source line.
3. Tabs are converted into enough blanks before lexical analysis.
Therefore, in both the value in the source line, they are
treated as some number of blanks.
4. Tabs are treated as the start of line-end comments.
The last two interpretations make it difficult to create character literals
containing tabs. All of these interpretations are permitted under the
current standard because tabs are not part of the FORTRAN character set.
If X3J3 does not choose to standardize the meaning of tabs, it should
at least standardize the meaning of non-Fortran characters in character
literals.
Yours truly,
Bob Corbett
uunet!elxsi!corbett
ucbvax!sun!elxsi!corbetthirchert@uxe.cso.uiuc.edu (07/08/89)
There has been some discussion of whether the tab character should be allowed in Fortran 8x source. Although many processors allow tabs, there a many different interpretations given to them. The problem with standardizing existing practice in this kind of situation is that for every program that becomes standard-conforming, there are probably two or three that are "broken" because the vendors old extensions no longer works. Therefore, I believe it would be a mistake to try to standardize the use of tab in the existing source form. However, it would probably be possible to support tab in the new source form, since there is no existing practice to break and the analogies to the existing fixed form extensions are largely indistinguishable in the new source form because of the lack of specific column boundaries. This could probably be handled in a manner similar to the way lower case letters are handled; i.e., if a processor has additional "white space" characters, they are treated as equivalent to blank in essentially the same circumstances as lower case letters are treated as equivalent to upper case letters. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications