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: C-mantics
Message-ID: <1636@ut-ngp.UUCP>
Date: Sat, 20-Apr-85 19:42:19 EST
Article-I.D.: ut-ngp.1636
Posted: Sat Apr 20 19:42:19 1985
Date-Received: Mon, 22-Apr-85 02:20:54 EST
References: <452@hou2g.UUCP>
Distribution: net
Organization: U.Texas Computation Center, Austin, Texas
Lines: 86

From: vdb@hou2g.UUCP (R.VANDERBEI)
>C is perhaps the nicest language I've seen (except APL) however I
>do have some criticisms:
>
>(1) Operators, functions and procedures should not have "side effects".
>
>   (a) For operators, this means that no operator should ever be 
>       allowed to change the value of its operands.  This eliminates
>       the possibility of "slangy" type operators like the increment
>       operator  ++   in C among others.

Where's the beef?  Side effects are bad only if misused.  Anything is
bad if misused.  Ever seen a 6-layer deep "structured" construction?

>                                          Also the assignment operator
>       is in fact not an operator but is a "copy statement".

Read K&R.  Assignment *is* an operator.

>   (b) For functions, this means that a function should only be allowed 
>       to alter the values of locally defined variables (one of which
>       is returned to the calling statement).  It is a terrible bastard-
>       ization of the meaning of a function to allow it to change the
>       values of any of its arguments or any variables which are defined
>       at a higher level.
> [...]
>                   One should define a structure which has fields for all 
>       the relevant printer information and then initialize a variable say
>       prn which contains the starting values for these parameters.  Then a
>       function call would look like this:
>   
>               prn = print(prn, ... ).
>
>       prn  goes in as input containing the current state, print  returns
>       a variable of the same structure which contains the updated information
>       and the  =  copies the information into  prn.

I fail to see the essential difference between this example and simply
passing &prn to the function.

>                                                      This is only an example
>       I think a language should supply such functions as print and, where 
>      appropriate, take advantage of mare streamlined semantics and more effic-
>       ient implementations.

The language should supply functions such as 'print'?!  Bogus.  This idea
violates the very soul of modularity.

>(2) All variable names should represent memory locations and not the value at 
>   the location.  Then operators have to be defined appropriately.

Try BLISS.

>   For 
>   instance, the plus operator  +  would be defined so that x+y would mean:
>   "add the value stored at location x to the value stored at location y
>   and return a pointer to the location where the result is stored".

You want this kind of magic to go on underneath a language used to write
operating systems?

>   Pointer arithmetic can be accomplished by the notation  x[j]  which
>   would represent the memory location x plus j times the length of
>   the structure to which x points.

This is a *very* confusing syntax.

>3. The assignment statement  =  should be the only way of actually copying
>   one area of memory into another.

No '+='?  Oh, sorry, that's changing one of your arguments.  But doesn't
your definition of '=' have that same problem?

> [..]
>4. In the definition of a stucture, one should be able to specify how 
>   operators act on newly defined structures.

You maybe really want an object-oriented language?

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