C-mantics

[Ken Montgomery]

From: vdb at 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 at ut-ngp.ARPA  [for Arpanauts only]