Xref: utzoo comp.lang.c:8586 comp.lang.misc:1338
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: The need for D-scussion (was Re: D Wishlist)
Summary: It can be fixed in the language; the notation needs simplification.
	 Can the compiler handle it?
Message-ID: <727@l.cc.purdue.edu>
Date: 27 Mar 88 12:22:33 GMT
References: <12176@brl-adm.ARPA> <1988Mar11.215238.976@utzoo.uucp> <3177@haddock.ISC.COM>
Organization: Purdue University Statistics Department
Lines: 74

In article <3177@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
> In article <10763@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
> >In article <719@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> >>Furthermore, returning a list of values for a function is far different from
> >>returning a structure.
> >
> >If so, the compiler should be improved.  There is no theoretical difference.

If so, there is at least confusion.  As I read K&R, a struct is a memory
assignment.  In some cases the memory assignment can be transferred to the
register file.  A list consists of items each of which has its own location.
It does not convey the impression that the locations of the items in the list
have any relation to each other.  One item can be a register, another a byte
local to the program, another an external float, we may possibly have both
local and external arrays, etc.

Generalizing the K&R struct cannot solve the problem.  If an external is to be
in the object, we have the problem of multiple definition.  Furthermore, if I
use the same type of list several times, with different arguments each time, it
is merely necessary to type in the relative arguments.  If we want to use the 
x.y struct notation and have the list expanded, we can easily do it with a
#define statement, but the other way is hard to do.  We are dealing with
different constructs.

> Or perhaps the language should be improved.  In C, the div() function returns
> a struct.   .....

> In Lisp, you're still returning an aggregate.  Things are a little better,
> because you can tighten the scope:
>   (setq z
>         ((lambda (qr) (+ (* (car qr) (car qr)) (* (cdr qr) (cdr qr))))
>          (div x y)))
> 
> In Forth, you can actually return multiple values (as opposed to returning a
> single value of aggregate type):
>   x @ y @ div  dup *  swap dup *  +  z !

In Lisp, the language certainly suggests that at some time there is a real
machine object called qr.  The way I am proposing the list, this is never
more than a virtual object, and does not need a name.  However, the user
assigns names to the elements of the list, and refers to them, rather than
having to write (car qr) and (cdr qr).  I am not saying that the user must
not set up the suggested notation, rather that he need not.

The Forth example requires that the stack exist.  I think that this may
make it extremely difficult for a compiler to "do what is natural."  It is
likely that the "natural" thing to do is far more efficient also.

> There's a certain elegance here which is lacking in the first two.  The qr
> temporary has been absorbed by the syntax of the language, in exactly the same
> manner as the temporary results of the "*" operator in all three examples.
> 
> I don't know if this is what Herman was talking about, but in this sense the
> current C model is lacking.  Whether this could be "fixed" in a C-like
> language is another question.

Too much elegance, and not enough simplicity.  Both versions are unnecessarily
complicated.  From the standpoint of a computer language, how can there be any
difficulty in allowing operators or procedures to produce lists?  I doubt that
the notation

	q,r = a _div_ b

will confuse a human reader of this article.  Whether we have, by ignoring 
this problem in the past, messed up our current compilers so that it is
necessary to do a complete rewriting rather than a fix is another matter.

> Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet