daven@lll-crg.ARPA (Dave Nelson) (04/09/85)
> brooks@lll-crg.ARPA (Eugene D. Brooks III) writes: > A committee ... is implementing the full C language with one minor > modification. In order to have compatibility with Fortran all subroutine > parameters will be passed by address. > As a consultant to the above committee, I should mention that, in fact, TWO minor modifications to standard C semantics were proposed: the one Dr. Brooks mentioned (I just can't see how people can get so steamed up over such a slight modification), and another that will simplify our program conversion process IMMENSELY: we are adding "equivalence" as a valid storage class. Still a few details to be worked out, though, before we propose it to the C standards committee. D. O. Nelson (daven@lll-crg)
kjm@ut-ngp.UUCP (Ken Montgomery) (04/21/85)
[Get out the asbestos... :-)] From: daven@lll-crg.ARPA (Dave Nelson) >> brooks@lll-crg.ARPA (Eugene D. Brooks III) writes: >> A committee ... is implementing the full C language with one minor >> modification. In order to have compatibility with Fortran all subroutine >> parameters will be passed by address. >> > >As a consultant to the above committee, I should mention that, in fact, >TWO minor modifications to standard C semantics were proposed: the >one Dr. Brooks mentioned (I just can't see how people can get so steamed >up over such a slight modification), It's not a "slight modification". It's a gut-rip of the semantics of the language. It will break thousands of lines of currently working code. It will subject us to the painful nonsense of allocating "scratch" variables in functions just to avoid modifying the calling routine's variables. It will also subject us to the equally painful bogosity of allocating extra variables to use as actual parameters to other persons' routines (since they might alter their arguments, and thus rudely cause a *nasty* sort of bug). This change will cause an enormous conversion, coding, and maintenance headache. > and another that will simplify our >program conversion process IMMENSELY: we are adding "equivalence" as a >valid storage class. So instead of fixing the problem (I never saw why EQUIVALENCE even existed in the first place), you want to perpetuate it. >Still a few details to be worked out, though, before we propose it to >the C standards committee. I'm not trying to knock the idea of a vectorizing C compiler. I also don't mean to say you shouldn't have the features you want/need in a language. However, your proposed modifications are incompatible with the current definition of C. If you really need the features proposed above, put them in; but *PLEASE* don't try to call the result C. >D. O. Nelson >(daven@lll-crg) -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cats and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ut-ngp.ARPA [for Arpanauts only]
peters@cubsvax.UUCP (Peter S. Shenkin) (04/22/85)
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.wcs@ho95b.UUCP (Bill Stewart) (04/24/85)
I suspect that the motivation for a call-by-address C is to have something more useful than FORTRAN-66, but that won't confuse fortran programmers. A couple of solutions, more reasonable than brain-damaging C - - Fortran-77 The language assumes call-by-reference, and could easily enough tolerate having recursion added (as UNIX f77 does.) If all you really want are control structures and recursion, this is a good place to start, and it will keep old programs working. I suppose yu could also add pointers - the resulting language would resemble fortran more than call-by-ref resembles C. - PL/I Well, some reasonable-sized subset of PL/I. The language has pointers, of sorts. There are lots of six-foot-thick manuals for the language, and it has a few features useful for scientific programming that C doesn't have, specifically arrays with variable dimensions (you can declare A(N,N), where N is a parameter passed to a subroutine). - APL an inherently vector-oriented language should be easy to adapt to a vector-processor, and you it's a nice language for expressing mathematics, and for debugging on your "slow" computer before you turn it loose on the real data. Bill Stewart
jmsellens@watmath.UUCP (John M Sellens) (04/24/85)
It was a JOKE. Stop discussing it.
guy@sun.uucp (Guy Harris) (04/24/85)
brooks@lll-crg.ARPA (Eugene D. Brooks III) writes: > A committee ... is implementing the full C language with one minor > modification. In order to have compatibility with Fortran all subroutine > parameters will be passed by address. 10 million readers write something on the order of: > "minor" modification? You've got to be out of your cotton-pickin' minds! > That's not C any more! Somebody else then writes: > As a consultant to the above committee, I should mention that, in fact, > TWO minor modifications to standard C semantics were proposed: ... > and another ... we are adding "equivalence" as a valid storage class. OK. Would Mr. Brooks, or somebody else associated with the first and/or third postings, please settle once and for all whether this was an April Fool's joke or not? The combination of the two proposed changes reads to *me* like such a joke; I think it was even posted around April 1. However, either 1) it's not a joke or 2) a hell of a lot of readers didn't get the joke. If it is a joke, would somebody confirm it so we can stop debating the merits of such a change to the language? Guy Harris