[comp.lang.fortran] Fortran 8x features, case sensitivity.

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