Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!gatech!csun1!weyrich
From: weyrich@csun1.UUCP (Orville Weyrich)
Newsgroups: comp.lang.fortran
Subject: Re: Character aliases are Satanic extensions
Message-ID: <177@csun1.UUCP>
Date: 10 May 89 21:37:19 GMT
References: <592@mbph.UUCP>
Distribution: na
Organization: Univ. of GA, CS Dept., Athens
Lines: 46

From article <592@mbph.UUCP>, by hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM):
> VMS fortran allows a user to enter character data typed as logical,
> byte, integer, real, double precision, dimension, probably complex and
> the proper character type "character."  VMS fortran allows character
> data to be assigned to these alias types by arithmetic assignment or by
> a data statement or non character functions or by using the read
> statement.
> 
> The use of these Satanic extensions by the VMS implementation of Fortran
> scores a 9.73 in the Fortran demolition derby; it is a robust attempt to
> demolish the concept of typing!  My compiler quite logically expects
> character data to be typed "character."  It is real shame that FORTRAN
> is not a standardized language!

What you describe was correct FORTRAN-66, before a character data type existed.
The VMS compiler would probably reject the program if you used the
/STANDARD switch on the compiler.  FORTRAN is a permisive standard that
stresses what is required to be supported. It does not prohibit the support
of extensions or anachronisms as long as they do not directly conflict
with required features.

I agree that a filter program that removes anachronisms would be nice, and I
have played around with such things.  But it is not an easy task. Consider
for example one old program that I had the misfortune (more positively, the
experience :-) of porting: It had an array of double precision values which
was used for a symbol table.  Some elements of the array stored character
data and other elements stored double precision values. No way that that
program could be redone using only standard FORTRAN-77 without completely
rewriting the symbol table code (and this code was developed when the
idea of data abstraction and information hiding etc. was not in vogue :-( ).

Another problem is that automatic conversions often obfusacate the code even
worse than it already is.  For example, how would you translate arithmetic
IF's, computed GOTO's, and assigned GOTO's without adding still more goto's
and more IF ELSEIF ELSE statements?

On the other hand, I would expect that it would be very easy to write a
filter that "tokenized" FORTRAN source code so that a future revision of
FORTRAN could do away with the archaic "blanks not significant" syntax.
Unfortunately, this might break some existing preprocessors. You can't
please everyone.
-- 
Orville R. Weyrich, Jr.          | UUCP    : ...gatech!csun1!weyrich
Department of Computer Science   | INTERNET: weyrich@csun1.cs.uga.edu
University of Georgia            |
Athens, GA 30602 USA             | MA BELL : (404) 542-1082