Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: by-ref parameters, aggregate constants, etc
Message-ID: <3100@umcp-cs.UUCP>
Date: Sat, 23-Aug-86 23:52:10 EDT
Article-I.D.: umcp-cs.3100
Posted: Sat Aug 23 23:52:10 1986
Date-Received: Sun, 24-Aug-86 03:14:28 EDT
References: <522@bunny.UUCP> <6229@sun.uucp> <161@BMS-AT.UUCP>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Distribution: net
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 83

>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