jlg@a.UUCP (Jim Giles) (03/03/88)
There have been a few people who remarked on the proposed Fortran 8x standard on this newsgroup. I feel that the discussion has been a bit hampered by combining comments about different features into large monolithic submissions. I wish here to initiate discussions on some of these features one at a time. First, to set the record straight, the correct spelling is 'Fortran' not 'FORTRAN'. I don't know why, but both ANSI and ISO use the first spelling. No one uses 'fortran' at all. The criterion for Fortran 8x features (in my opinion) should be to certify existing practice or to extend the language in a significant way. I will use this criterion throughout this discussion. As an example of the use of this criterion (and as the first feature to be addressed) I will remark upon one of the features requested on the net by Bob Corbett (ELXSI). The suggestion was that lower case letters should be considered distinct from upper case letters in user-defined names. This is certainly contrary to existing practice. Many Fortran compilers only recognize one case (sometimes it lower!). Most compilers that recognize both cases don't distinguish between them. The only exceptions I know are both UNIX f77 compilers (they probably distinguish because of a bias toward C which does). Since case sensitivity is not standard practice, it should only be included if it adds significantly to the functionality of the language. Here again, it fails to meet the test. In fact, it significantly reduces functionality in many contexts where people are relying on case insensitivity to make code more readible, to document code, or to process code automatically. The only increase in functionality this feature would provide is marginal - making more possible user-definable names available. But if 31 characters is not sufficient name space already, you've got other problems. I think it's just as well to leave out case sensitivity. J. Giles Los Alamos P.S. This discussion is not occuring in a vacuum. Just because the deadline for public comment has passed doesn't mean that it's too late to effect the standard. Many of the members of the standards committee read this newsgroup! Really GOOD ideas from the general public WILL be considered before the standard is ratified.
ags@s.cc.purdue.edu (Dave Seaman) (03/03/88)
In article <500@a.UUCP> jlg@a.UUCP (Jim Giles) writes: >First, to set the record straight, the correct spelling is 'Fortran' >not 'FORTRAN'. I don't know why, but both ANSI and ISO use the first >spelling. No one uses 'fortran' at all. The correct name of the new (8X) language is 'Fortran'. The correct name of the old (77) language is 'FORTRAN'. -- Dave Seaman ags@j.cc.purdue.edu
reeder@ut-emx.UUCP (William P. Reeder) (03/04/88)
In article <500@a.UUCP>, jlg@a.UUCP (Jim Giles) writes: > > First, to set the record straight, the correct spelling is 'Fortran' > not 'FORTRAN'. I don't know why, but both ANSI and ISO use the first > spelling. No one uses 'fortran' at all. > First, 'PASCAL' isn't spelled 'Pascal', 'ALGOL' isn't spelled 'Algol', 'C' isn't spelled 'C' (oops, experimental error :-), and 'FORTRAN' shouldn't be spelled 'Fortran'. ANSI tried (on page I, lines 22-23) to redefine the spelling of FORTRAN, but I reject this just as I reject S8 as a new standard. > The criterion for Fortran 8x features (in my opinion) should be to > certify existing practice or to extend the language in a significant > way. I will use this criterion throughout this discussion. > I think (but only when absolutely neccessary ;^) that the standards committee should generally only standardize existing practice. I am willing to make an exception for those features which (lots of) users have wanted but no vendor has been willing to implement (are there any that fit this criterion?). The reason that I don't want committees inventing significant extensions to ANY language should be obvious -- do we need any more camels or platypusses (or is it platypi, hmm...) ? -- William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu The Looniversity of TexMex at Autism, Consternation Central, Austin TX 78712 DISCLAIMER: I speak only for myself, and usually only to myself.
eugene@pioneer.arpa (Eugene N. Miya) (03/04/88)
In article <1067@ut-emx.UUCP> reeder@ut-emx.UUCP (William P. Reeder) writes: >First, 'PASCAL' isn't spelled 'Pascal' Well if you want to be picky it IS spelled 'Pascal.' After Blaise, and it's not trademarked, and and and and no it's not an acronym for Pasadena, California as I know some people believe. From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA ex-ANSI X3/J9 JPC "You trust the `reply' command with all those different mailers out there?" "Don't Send mail on something as dumb as this" {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
reeder@ut-emx.UUCP (William P. Reeder) (03/05/88)
In article <5526@ames.arpa>, eugene@pioneer.arpa (Eugene N. Miya) writes: > In article <1067@ut-emx.UUCP> reeder@ut-emx.UUCP (William P. Reeder) writes: > >First, 'PASCAL' isn't spelled 'Pascal' > > Well if you want to be picky it IS spelled 'Pascal.' After Blaise, > and it's not trademarked, and and and and no it's not an acronym for > Pasadena, California as I know some people believe. > Thanks for the correction :-) -- William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu The Looniversity of TexMex at Autism, Consternation Central, Austin TX 78712 DISCLAIMER: I speak only for myself, and usually only to myself.
rick@svedberg.bcm.tmc.edu (Richard H. Miller) (03/09/88)
In article <500@a.UUCP>, jlg@a.UUCP (Jim Giles) writes: > > Since case sensitivity is not standard practice, it should only be included > if it adds significantly to the functionality of the language. Here again, > it fails to meet the test. In fact, it significantly reduces functionality > in many contexts where people are relying on case insensitivity to make > code more readible, to document code, or to process code automatically. > > The only increase in functionality this feature would provide is marginal - > making more possible user-definable names available. But if 31 characters > is not sufficient name space already, you've got other problems. Another important consideration is how much existing code becomes non-conforming by a proposed standard and the amount of trouble to make the code conform. If case sensitivity becomes standard, there will be many programs which have used case insensitivity to make them more readable will no longer work. This will require a massive effort to make them work and will certainly introduce a large number of very subtle bugs (VARa vs VarA). Richard H. Miller Email: rick@svedberg.bcm.tmc.edu Head, System Support Voice: (713)799-4511 Baylor College of Medicine US Mail: One Baylor Plaza, 302H Houston, Texas 77030