Xref: utzoo comp.lang.c:7864 comp.lang.misc:1151 Path: utzoo!mnetor!uunet!husc6!bloom-beacon!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 D Programming Language Message-ID: <700@l.cc.purdue.edu> Date: 6 Mar 88 11:13:17 GMT References: <25284@cca.CCA.COM> Organization: Purdue University Statistics Department Lines: 58 Summary: This is a weakness in every computer language I know In article <25284@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes: ........ > But how do I get stuff back. I can pass one thing back > via the return statement. To pass more than one thing I have to play > games. Things which are returned need a mechanism equivalent to pass > by address. No, what is needed is to abandon the mistaken notion that a function returns a single result. From day one, lists should have been allowed to the left of the replacement sign--this is not just for functions, but even for direct operators. For example, the infamous frexp function in C should not have the syntax y = frexp(x,&n); but y,n = frexp(x); This would, for example, allow n to be in a register, which is probably where it should be anyhow. Another example would be to have q,r = a///b; where the quotient and remainder are simultaneously produced. Possibly if that were in the language, we would not find the operation disappearing from hardware. ...... > > The following example is illustrative syntax only: > > [int *,int] foobar(); > .... > [ptr,flag] = foobar(arg) > int arg; > { > int *a, *b; > .... > return [a,1]; > .... > return [b,0]; > } I would drop the brackets, but otherwise the notation is reasonable. Another thing is to allow the return value to be stored _before_ the return statement. It may be desirable to do other computations after computing the value, especially for functions with side effects, such as random number procedures. -- 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