osd7@homxa.UUCP (The Moderator) (11/14/84)
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