(SC22WG14.323) Re: reaction to Variable Length Array Proposal <9302111958.AA09162amoonshine.llnl.gov>

[uunet!netcom.com!segfault!rfg]

James A. Crotinger writes:

    I think you're missing the point. People want to convert their
  libraries to C while retaining the same API so as not to break
  { existing } customer applications { written in FORTRAN }.

Who wants to do that???

What possible purpose would it serve to take a perfectly good, fully
debugged, time-tested set of FORTRAN library routines and simply rewrite
them in C?

Perhaps this might be useful as a training exercise when taking old
FORTRAN programmers and retraining them to understand C, but other than
that I can see no commercial, military, or industrial value in such a
exercize.

  The whole world is not going to convert to C overnight...

No, but it seems to be the view of some participants that the entire
world *should* convert (eventually) from FORTRAN completely over to C.
I question the real need (and possibility) for such a massive and uni-
versal shift, but that is besides the point.  We agree that *some*
folks may indeed have good reason to convert *some* code from FORTRAN
to C, but we now are hearing arguments that we need to bend over back-
ward to ease such transitions, and that in fact, what we need to do
is to design a new language which is a superset of both FORTRAN and C
(with all of the features of both).

I agree that FORTRAN has many nice features for numerical computing, and
I can see how a number of these (e.g. type complex) might be painlessly
integrated into C without seriously compromizing the very features of C
which have made it so popular, but I disagree with the notion that we
would get a better language by taking the worst features of some set of
languages and throwing them together into one big pot.  That was tried
back in the 60's and the result was called PL/I.  It was never terribly
well received.

  ...and if C can't easily interact with Fortran, then it
  probably doesn't have a prayer of becoming widely accepted for
  numerical computing.

In general, C *can* easily interoperate with FORTRAN code, and it would
be a mistake to claim (as some seem to wish to do) that the sky will
fall if FORTRAN programs might occasionally have to be adapted in minor
ways when they are linked to brand new C compilation units rather than
old FORTRAN compilation units.

(I wonder if some of these folks know about "Hollerith constants".  Ya
don't see much FORTRAN code which those in there anymore now do you?
Times change.  So does code.)

I'm worried that if we take this "interoperability" argument to its
logical conclusion, we'll come around to the view that we need to add
yet more bizzare hacks to C in order to allow it to fully interoperate
with all that dusty deck FORTRAN code.  For example, FORTRAN programs
sometimes pass stuff via named common blocks, right?  So shall we add a
"named common" feature to ANSI C?  Some F77 program pass "alternate
return" parameters to called routines.  So do we need to add another
new data type to C which we can use to declare the corresponding formal
in such cases?  Will we need to add some new form of return statement
(perhaps a "go_back_to" statement) in order to fully support FORTRAN
"alternate return" parameters?

I could go on, but I'll stop here.


// Ronald F. Guilmette
//    domain address:	rfgasegfault.uucp
//    uucp address:	...!uunet!netcom.com!segfault!rfg