chris@umcp-cs.UUCP (Chris Torek) (08/24/86)
>In article <6229@sun.uucp> guy@sun.uucp (Guy Harris) writes: >>This may, in fact, also be an argument for reference types a la C++; there, >>your routine "foo" would be written as >> >> foo(c) char &c; { ... In article <161@BMS-AT.UUCP> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes: >I don't like this. I have no great love for this syntax either; but how else do you propose to add by-reference parameters? (I believe that by-reference parameters are, in general, bad, at least if I cannot tell from the caller that the parameter is modifiable. I would not add them at all. Clearly Bjarne Stroustrup and I disagree.) >I would like to see variable size arrays allowed as local parameters. >This would be a lot more efficient than using malloc(). ... or alloca() (since it requires a function call). These would indeed be useful, if more expensive than fixed arrays. Actually, I think a general stack allocator, possibly `built in' to the language, would do: were alloca() a reserved word, for example, it could be expanded in line. (Indeed, it may not always be possible to allocate stack objects in a called function, but it is not hard for the caller to manage the trick.) >I would like to "operator definition" which would allow you to opdef >say '+' to cause it and its two arguments to be replaced by a macro >called with the two arguments whenever the arguments are of a type >specified in the definition. C++ has this sort of thing, though the expansion does not use macros (inline functions are perhaps legal). >I would like to see "structure constants" which would allow assignment >to aggregate types. General aggregate types are, I think, the one thing that would really `round out' the C language. Currently the only legal aggregate type is `array N of char', expressed as "string" If C were given aggregate types, it would then seem appropriate to me also to alter array names to `be' the entire array. But such changes would be quite substantial, and the language should not then be called `C'. >Macros would be nicer with "imbedded functions". > >#define foo(x,y) { float a = 0.0; while (x) { a += y * x--; }; return a; } Inline functions are clearer, I think: inline int foo(x, y) int x, y; { float a = 0.0; while (x) a += y * x--; return (a); } >This construct is distinguished by the use of '{}' in a context >requiring a value. The return is optional, the value of the last >expression is used. Would early `return's be legal? What if the last statement is not an expression? (Back up to the most recent expression?) Such a change requires careful thought to ensure that all the elements of the language still `mesh' properly. One of the nicest things about C-as-it-is-now is that most of its primitives do indeed mix well. >Perhaps loops should be allowed in comma expressions instead. This sounds to me ill-advised. Inline functions are semantically obvious; `embedded' functions or loops are less lucid. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
tainter@ihlpg.UUCP (Tainter) (08/25/86)
> >In article <6229@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >>This may, in fact, also be an argument for reference types a la C++; there, > >>your routine "foo" would be written as > >> foo(c) char &c; { ... > I have no great love for this syntax either; but how else do you > propose to add by-reference parameters? (I believe that by-reference > parameters are, in general, bad, at least if I cannot tell from > the caller that the parameter is modifiable. I would not add them > at all. Clearly Bjarne Stroustrup and I disagree.) > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) The win for by-reference parameters is the syntax of their use in the callEE. I do extensive personal programming in pascal and C. When rereading pascal with by-reference parameters I do at times lose track of what is a var parameter at the callER level but never at the callEE level. C fixes this but at the expense of excessive clutter and confusion with pointers inside the callEE. I propose: dowa(a) int &a; /* this declares a to be a pointer to an whose use has the syntax of an auto int. this is a pascal style var parameter implementation of by-reference */ { int b; a = rand(); b = rand() + a; return b; } main() { int sr,fr; /* In the CALLER the pascal style var parameter implementation gets superceded by explicit address of and pointer syntax */ sr = dowa(&fr); /* still required to pass address of */ printf("first random = %d, sum of two randoms = %d\n",fr,sr); /* this would also be legal: */ pfr = malloc(sizeof (int)); sr = dowa(pfr); printf("first random = %d, sum of two randoms = %d\n",*pfr,sr); } Basically it provides the same "pointer" syntax at the callER and a friendly by-reference syntax at the callEE. --j.a.tainter
stuart@BMS-AT.UUCP (Stuart D. Gathman) (08/27/86)
In article <3100@umcp-cs.UUCP>, chris@umcp-cs.UUCP (Chris Torek) writes: Inline functions are clearer, I think: inline int foo(x, y) int x, y; { float a = 0.0; while (x) a += y * x--; return (a); } -- Yeah! That is much better! (I just didn't think of it.) -- Stuart D. Gathman <..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>