"Vectorizing C compiler for the Cray"

[Peter S. Shenkin]

NOTE:  I tried to send this to Brooks via net mail, but one of the sites
in his path came up as a bad site name... so thought I'd post this to the
net.  

Greetings!

Re: a vectorizing C-compiler:  I'm one of those who looks forward to it.
I do simulations of biomolecules (dynamics & energy minimzations) using
mainly FORTRAN programs of 25k lines on up, but we are a UNIX site and
I mostly write in C these days, personally.  We are getting a Star
array processor soon, and are doing hardware development for special-
purpose processing, and will be using maybe 100 hrs of Cray time in the 
coming year...  so you see why I'm interested.

However, regardless of those who don't see C as relevant to higher-level
applications programming (C users really span a broad range of end-use
interests and are sometimes blind to or unaware of those of their fellows),
I do agree with those who feel that call-by-address would be
a mistake in an otherwise C-like language.  Here are a few of the *non-
religious* (!!) arguments against it.

	1.  It breaks almost every existing C program -- at least all the
	    ones I've written, and I'm more careful than most to write 
	    portable C.  It would be nice not to have to rewrite everything
	    when I go to a Cray or an array processor. 

	2.  A common existing extension of C is the "fortran" keyword;
	    I believe in use a function declaration like
	        fortran function(a, b, c)
	    already means that function will be passed the addresses of
	    the arguments (that is, &a, &b, and &c).  Passing mention to
	    this is made on p180 of Kernighan and Ritchie's book.  Why
	    make mandatory what FORTRAN programmers find convenient, when
	    it already exists as an option in the language?

As with most languages, people that use C and are skilled in it develop
a certain idiom and familiarity -- certain habits that it goes against the
grain to break, and which cause one to bitch and groan if forced
to change.  It seems that the only reason you're making this change is to give
FORTRAN programmers an environment closer to what they're accustomed to;
but, if they're going to learn the rest of C, why not make it something that
C users will like, and add the "fortran" keyword for die-hards?  Seems like 
we could have the best of both worlds.  Call by argument is really a very
nice and useful feature, which C-programmers will sorely miss.

You made reference in your original article (I don't have a copy) to something
like "conformance with FORTRAN usage."  Let me just note that it is easy, at
least under UNIX, to link FORTRAN and C subroutines, even with the existing
difference between call procedures.  For example:

C     FORTRAN ROUTINE
      SUBROUTINE MULT(RESULT,A,B)
      RESULT=A*B
      RETURN
      END

/* C calling routine  */
main()
{
	float a=3.14159265, b=2.7182818, result;

	mult_(&result, &a, &b)
	printf("%f\n",result);
}

(Under UNIX, FORTRAN is insensitive to case unless compiled with a special
flag.  The FORTRAN compiler appends an underbar to all fortran routines for
use by other calling languages such as C.)

Well, sorry.  This has been too long-winded.  You should know there is a
"loyal opposition."  You never said what is to be gained by your
change, except to make life easier for those who have previously used only
call-by-address languages, and perhaps for compiler writers.   What about 
the rest of us?

Dr. Peter S. Shenkin;  Department of Biological Sciences; 1002 Fairchild;
Columbia Univ., New York, NY  10027		philabs!cubsvax!peters

P. S.  I'd like to continue the discussion, and especially hear 
why you like call-by-argument, by return mail, if you find the net
distasteful.