NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/fortran/3045

Internet Message Format | 1992-08-14 | 6.0 KB

Path: sparky!uunet!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!uw-beaver!zephyr.ens.tek.com!ogicse!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!burley
From: [e-mail] (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: What extensions do you use?
Message-ID: <[e-mail]>
Date: 14 Aug 92 20:06:02 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
Lines: 97
In-reply-to: [e-mail]'s message of 14 Aug 92 10:12:08 GMT

In article <[e-mail]> [e-mail] (John V. Langer) writes:

           I hope and pray Craig Burley will include it in his new
           compiler.

It [support for hollerith] is in the new compiler.  It pretty much went in
from the beginning.  What I'm unsure of is just how much support for
hollerith I have vs. how much is needed.  It's there for DATA, and for
some other places as well.  I guess that's what the upcoming alpha test
will do, among other things: help find what needs to be added to make
the compiler useful.  (For example, it doesn't yet support IMPLICIT
UNDEFINED, because that isn't the extension I'm familiar with.  It does
support IMPLICIT NONE.  Presumably if somebody wants the former, they'll
be willing to send me a detailed spec on how it works so I can implement
it _once_.  :-)

However, GNU Fortran currently doesn't try and support any "reserved name"
extensions with one exception (selectable when compiling it) -- DEC's
weird PARAMETER statement (what does "PARAMETER X = 3.0" mean?).  That is,
disambiguation via the technique "gee, it _looks_ like an XYZ statement,
so I'll assume it's that instead of an assignment or whatever" isn't in
GNU Fortran.  It's easy to add, but I think for now it is even easier to
just see whether people are able to change code so their programs start
out with "REAL FUNCTION FOO()" rather than "REAL FUNCTION FOO" (GNU Fortran
will assume the latter is a type declaration of a REAL variable named
FUNCTIONFOO) and so on, _then_ decide what kinds of reserved-name
disambiguations are really needed.  (Of course, the standard reserved name
of "END" in a particular context is _always_ detected by GNU Fortran, since
at its heart, it really wants to be a standard-conforming compiler. :-)

One of the problems of all these extensions is that the vendors who supplied
them didn't do a very good job of describing, in detail, just how they fit
into the language, and without their compilers available to me to attempt
to figure it out, I can only guess.

For example, what does the following statement do?

      REWIND 2H=X

Since a unit number corresponding to hollerith "=X" seems absurd, I'm
assuming it's an assignment statement.  But it could be a REWIND statement.

Also, some compilers (and GNU Fortran) support typeless constants of the
form 'nnnn'O (for Octal).  They also support inline comments.  What is
to be made of a statement like:

      X = '200   ! Is this a comment or part of a char string?
     &   'O

The GNU Fortran front end has to decide as soon as it sees a given token
whether the next token will be "literal" (as in character-string) or
"normal" (ignore spaces and comments).  If comments are supported within
typeless constants as they are (at least in GNU Fortran) in constants of
the form O'nnnn', GNU Fortran wouldn't be able to figure all cases out
properly.  And I don't know what various vendors would do.  The above
case is fairly easy to guess (though GNU Fortran complains because the
comment is considered an invalid part of an octal number), but what about:

C                                                                   column
C                                                                      72
C                                                                       |
C                                                                       |
C                                                                       v
      CALL                                                       FOO('1!'
     &'O)!')

Is this "CALL FOO('1'O)" or "CALL FOO('1!''O)!')" (the latter passing a
character string with the value "1!'O)!")?  GNU Fortran currently always
chooses the latter, since it lexes what comes after the first apostrophe
as a character string and doesn't try and relex if that produces a parsing
or semantic error.

As you can see, this is the kind of thing that drives me straight up the
wall, and that's why, aside from the extensions I had decent (yet not entirely
adequate) specs on, I have so far avoided adding things willy-nilly until I
can really _see_ just how they fit into the language.  (This gets back to the
precisionless constant controversy as well, since I know of no completely
detailed spec for how precisionless constants work, and don't want to attempt
to do _my_ version of them without knowing what others who say they want the
feature _mean_ by saying that -- in precise terms.  And I'd much prefer to get
paid for that work anyway, since I don't particularly like the feature yet.)

Even supporting pure ANSI FORTRAN 77 has its difficulties.  I uncovered bugs
not only in my front end when I started integrating with the GNU back end but
also in AT&T's f2c program, especially in regards to the fifty different ways
to parse a READ statement, depending on things like the phase of the moon,
whether you use a 1040, 1040A, or 1040EZ tax form, etc.  :-)  Add vendor
extensions to the mix, especially given that most of them seem to have been
hastily added (syntactically speaking) to address a short-term need and got
ensconsed as long-term solutions because of "compatibility", and things get
really hairy.  I don't want to even _think_ about things like CRAY pointers
and Fortran 90 just yet.  I'll probably feel better about things once a
beta release happens.  (Don't ask me when that'll happen, just send cash. :-)
--

James Craig Burley, Software Craftsperson    [e-mail]
Member of the League for Programming Freedom (LPF)