Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ut-ngp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!ut-sally!ut-ngp!kjm
From: kjm@ut-ngp.UUCP (Ken Montgomery)
Newsgroups: net.lang.c
Subject: Re: "Vectorizing C compiler for the Cray"
Message-ID: <1635@ut-ngp.UUCP>
Date: Sat, 20-Apr-85 19:11:08 EST
Article-I.D.: ut-ngp.1635
Posted: Sat Apr 20 19:11:08 1985
Date-Received: Mon, 22-Apr-85 02:20:35 EST
References: <486@lll-crg.ARPA> <515@lll-crg.ARPA>
Organization: U.Texas Computation Center, Austin, Texas
Lines: 49

[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]