Standard C Digest - V1 #3

[The Moderator]

Mail your ideas and replies to the author(s) below or to cbosgd!std-c.
Cbosgd is reachable via most of the USENET nodes, including ihnp4,
ucbvax, decvax, hou3c....  Administrivia should be mailed to 
cbosgd!std-c-request.

**************** mod.std.c  Vol. 1 No. 3  11/13/84 ********************

Today's Topic:
	Reply to comments on the addition of aggregate constants...  (2)

----------------------------------------------------------------------

Date: Mon, 12 Nov 84 17:11:03 pst
From: hpdsa!decot (Dave Decot)
Subject: Re: aggregate constants

>   From: mcvax!guido (Guido van Rossum)
>
>   It is very unorthogonal that aggregates must contain only constants.
>   
>       static                       auto
>
>    constant expr                   any expression
>    constant aggregate              ---
>
>   I think that the empty space should be filled, if at all, with
>   "any aggregate", and not with "constant aggregate".  After all,
>   the ambiguities that are caused because braces are used both for
>   compound statements and for aggregates, could hardly become worse
>   when aggregates are allowed to contain variable expressions.
>   The semantics cannot be a problem either.  The order of evaluation
>   can be left unspecified (as with argument lists and operands of
>   binary and ternary operators).

I'm not sure what "very unorthogonal" means, but it also seems incomplete
to allow structures to be copied, but not arrays.  This analogous situation
has evidently not been a problem, however.  My proposal does not preclude a
later extension of the concept to aggregate expressions.  I think it unwise
to change the language too radically all at once.  (I am not aware of any
ambiguities in the use of braces, but the commas could be a problem.)

While it might be nice to have aggregate expressions, no one has yet suggested
a syntax for describing them, nor semantics for manipulating them.  Managing
aggregate expressions would also involve considerably more implementation work
than permitting automatic aggregate initialization, which I believe is a
well-defined concept.  Any proposal to extend languages before standardization
must be provably implementable.  In cases where implementations of my
suggested extensions might not be obvious, I have suggested one.

>   >           Even if the type is 'pointer to char', the string pointed to by
>   >    that part of the initial value is the same each time it is executed,
>   >    and is not affected by changes to previous instances of the string.
>   >    ... [implementation proposal] ...

>   This makes only sense if the same requirement is made for the use
>   of constant strings in general.  I prefer having all strings read-only,
>   which is in accordance with decent usage and fair expectation.

String constants are static where they appear in expressions.  While you might
prefer it, changing this would break almost all existing programs.  An important
difference between string constants and aggregate constants is that an
aggregate constant value may potentially end up at different addresses
(perhaps on the stack of some recursive procedure).  It is counterintuitive
to allow changes to part of one instance of such a constant to affect others
when the values are stored in variables that are supposedly local.

To put it another way, a literal string in an initializer can be considered
to be part of the initial value.  Whether it varies when automatic variables
are "initialized" with the same constant has no precedent.  Static initial
values should be static, and automatic initial values should be automatic.

Dave Decot  (ihnp4!decvax!ucbvax!hpda!decot)
----------------------------------------------------------------------

Date: Mon, 12 Nov 84 17:11:03 pst
From: hpdsa!decot (Dave Decot)
Subject: Re: Array proposals

>   From: utzoo!henry (Henry Spencer)
>
>   Has any of this been implemented anywhere?  With what results?  What were
>   the problems (both for the implementor and the customers)?  How much use
>   was made of the features?  Did it break any existing programs?  Did it
>   result in significant improvements in efficiency or readability in a
>   significant number of programs?

Thanks for your excellent questions.  They have not been implemented for C,
to my knowledge.  However, most of these concepts have analogues in existing,
well-used languages such as Pascal.  The ability to pass arrays by value
and to return them has been around for quite a long time, and it's not
difficult to implement within the framework and spirit of C.  For those
extensions whose implementations are not immediately obvious, I can
supply them.

I have designed these proposals so that they would not break existing
programs.  If you can find specific counter examples, please present them.

Array assignment and comparison would enable processors that have built-in
instructions for such operations to use them to advantage, which is not
currently possible.

The abstraction permitted by the ability to manipulate an array as a
single object is natural to several types of applications, including
three-dimensional graphics processing, vector analysis, and database
implementation.  Often I have wanted to set up a table to some known state
upon each entry to a function;  this is presently done by copying a static
table somewhere.  Unfortunately, even this cannot be done with a single
statement if the table is stored in an array.  So I usually put the array
into a structure so I can copy the structure!  Is there a better way to do
this with C the way it is now?

The language currently permits any object to be copied with a single
assignment statement or to be used as a value parameter or return value,
except for an object which is an array or function.  This proposal is a
natural extension.  (I will leave it to someone else to come up with
semantics for copying a function!)

>   If the answer to the first question is "no", then why is this being
>   suggested as part of the standardization of an existing language?

Why are external function declarations with typed formal parameters being
considered?  It is my understanding that type-checking was found to be
useful in other programming languages.  Almost every high-level language
allows arrays to be treated as variables.  Why not C?

Dave Decot  (ihnp4!decvax!ucbvax!hpda!decot)
--------------------------------------
End of Vol. 1, No. 3. Std-C  (Nov. 13, 1984  23:00:00)
-- 
Orlando Sotomayor-Diaz/AT&T Bell Laboratories/201-870-7249
		      /Crawfords Crnr. Rd., Holmdel WB 3D109, NJ, 07733
UUCP: {ihnp4, houxm, akgua, mhuxd, ...}!homxa!osd7