Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!rutgers!ucsd!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: i++, i+=1, i=i+1
Message-ID: <3695@lanl.gov>
Date: 16 Sep 88 19:05:29 GMT
References: <1123@nmtsun.nmt.edu>
Organization: Los Alamos National Laboratory
Lines: 45

From article <1123@nmtsun.nmt.edu>, by warner@hydrovax.nmt.edu (M. Warner Losh):
> Can we now get back to talking about FORTRAN, and what the damn committee
> is doing to our FORTRAN?  Ppppppplease?
> 
> flame off
> 
> C isn't FORTRAN.  FORTRAN isn't C.

I agree. But a lot of the C supporters (and others) _seem_ to want to 
make Fortran more like C.  Why discuss C in the comp.lang.fortran group
at all except to compare features that _might_ be useful.  I think there
are a lot of things in C that might (with substantial modification) be
useful for the Fortran committee to consider.  I _KNOW_ that the committee
is considering pointers.  The point is that it is clearly undesireable
for some of the (most touted) C features to _ever_ make it into Fortran.

In light of this, it is perfectly valid to examine C features (good and
bad) in the Fortran group.  It is also valid, if you think a C feature is
bad, to say so and give reasons why.  Here are some features that _might_
be nice to see in Fortran:

1) Pointers - but _not_ the way C does them.

2) A preprocessor - but _not_ as an required part of the language.
   A supplimentary standard for a preprocessor could be devised which
   would complement the Fortran language without being a built-in part
   of it.

3) Exception handling - but, again, as a supplimentary standard.  The
   supplimentary standard would describe a set of library routines which
   would provide the necessary functionality.  And, again, without being
   a built-in part of the language itself.

If you have questions about what constitutes a supplimentary standard,
the Fortran 8x proposal (which has been effectively shot down) devoted
appendix A to the subject.  Supplimentary standards have the advantage
that they are free to be designed with more than _one_ language in mind.

The above list is in no way exhaustive.  But the main idea is to keep
an open (but not an empty) mind about features.  Without doubt, C has
a lot of very desireable properties.  Fortran should take note of these,
but without copying the undesireable ones (of which there are plenty).

J. Giles
Los Alamos