by-ref parameters, aggregate constants, etc

[Chris Torek]

>In article <6229 at sun.uucp> guy at 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 at BMS-AT.UUCP> stuart at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu