www.digitalmars.com         C & C++   DMDScript  

D - Multiple return values - optimal ???

reply "Matthew Wilson" <matthew stlsoft.org> writes:
Walter,

Maybe you've followed c.l.c.m enough recently to have noticed that there's
been a bit of a to-do about single return value, or not.

I was wondering how good the code generator is in this regard. In other
words, can we write for logic, and have more than one return value, as
appropriate, without worrying about ineffiencies. (Hint: my expectation is
that we can :) )
Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I'm for multiple return values.  All it does it automate the process of
declaring a custom struct to hold the values.  Good syntax sugar.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgn5f$310g$1 digitaldaemon.com...

 Walter,

 Maybe you've followed c.l.c.m enough recently to have noticed that there's
 been a bit of a to-do about single return value, or not.

 I was wondering how good the code generator is in this regard. In other
 words, can we write for logic, and have more than one return value, as
 appropriate, without worrying about ineffiencies. (Hint: my expectation is
 that we can :) )
Sep 20 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Sean L. Palmer wrote:

 I'm for multiple return values.  All it does it automate the process of
 declaring a custom struct to hold the values.  Good syntax sugar.
 
 Sean
 
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgn5f$310g$1 digitaldaemon.com...
 

Walter,

Maybe you've followed c.l.c.m enough recently to have noticed that there's
been a bit of a to-do about single return value, or not.

I was wondering how good the code generator is in this regard. In other
words, can we write for logic, and have more than one return value, as
appropriate, without worrying about ineffiencies. (Hint: my expectation is
that we can :) )


 
 
 


but it requires the comma operator being replaces/removed does it not ?

e.g. what to make of
to do
a,b = func();
or would []'s be used
[a,b] = func();
[a,b] = [b,a];

look at LUA for an exmaple of a lang that handles multipul return values 
fairly well.

the logical conclusion to the above is that () for func calls should be 
replaces with [] (funcs take one param a struct)

int a, b; long c;
func[a,b,c] => calls one of
function( int, int, long )
function( struct { int, int}, long );
function( struct { int, int, long } );
function( int, struct { int, long } );

thats what it does currently for C calls on x86 anyway, just a little 
hard to provoke the compiler to let you see it as such, and it's not 
quite like that for D calls as the struct is upside down and the last 
param in a reg.
other arch's (e.g. arm its not quite right as the first 4*32bits of the 
  params are in the first 4 registers)
Sep 20 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkibrh$2jil$1 digitaldaemon.com...

 Sean L. Palmer wrote:

 I'm for multiple return values.  All it does it automate the process of
 declaring a custom struct to hold the values.  Good syntax sugar.


 but it requires the comma operator being replaces/removed does it not ?


Yes.  I'm not a big fan of C's comma operator anyway.  I do however like
C++'s ability to overload the comma operator... you can use it to build
lists.

The comma operator should not simply discard the left side... it should form
structs or tuples instead.

If you don't count variable parameter lists, functions take a struct and
return a struct, as you say.

I don't think you should worry about the calling convention.  Let the
calling convention fit the language;  don't compromise the language to
adhere to some arbitrary calling convention.

Sean
Sep 20 2003
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkii41$2ro0$1 digitaldaemon.com...

 "Mike Wynn" <mike l8night.co.uk> wrote in message
 news:bkibrh$2jil$1 digitaldaemon.com...

 Sean L. Palmer wrote:

 I'm for multiple return values.  All it does it automate the process






of

 declaring a custom struct to hold the values.  Good syntax sugar.


 but it requires the comma operator being replaces/removed does it not ?


 Yes.  I'm not a big fan of C's comma operator anyway.  I do however like
 C++'s ability to overload the comma operator... you can use it to build
 lists.

 The comma operator should not simply discard the left side... it should


form

 structs or tuples instead.

 If you don't count variable parameter lists, functions take a struct and
 return a struct, as you say.

 I don't think you should worry about the calling convention.  Let the
 calling convention fit the language;  don't compromise the language to
 adhere to some arbitrary calling convention.

 Sean


It need not return an implicit struct. A method may work directly on the
result values, as if they were passed as parameters. For example, the
following code:

(int, double) MyMethod(int i, double d)
{
    return (i * 2, d * 2);
}

int i;
double d;

i, d = MyMethod(10, 20.5);

could be translated in C like this:

void MyMethod(int *ri, double *rd, int i, double d)
{
    *ri = i * 2;
    *rd = d * 2;
}

A method working directly on the result argument would speed up the code.
Return variables could also be named, so as that the method works on them
individually:

(int ri, double rd) MyMethod(int i, double d)
{
    ri = i * 2;
    rd = d * 2;
}

Return values could also have defaults:

(int ri, double rd = 5) MyMethod(int i, double d)
{
    ri = i * 2;
    rd = d * 2;
}
Sep 21 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Achilleas Margaritis wrote:

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bkii41$2ro0$1 digitaldaemon.com...
 

"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkibrh$2jil$1 digitaldaemon.com...


Sean L. Palmer wrote:


I'm for multiple return values.  All it does it automate the process






 
 of
 

declaring a custom struct to hold the values.  Good syntax sugar.


but it requires the comma operator being replaces/removed does it not ?


Yes.  I'm not a big fan of C's comma operator anyway.  I do however like
C++'s ability to overload the comma operator... you can use it to build
lists.

The comma operator should not simply discard the left side... it should


 
 form
 

structs or tuples instead.

If you don't count variable parameter lists, functions take a struct and
return a struct, as you say.

I don't think you should worry about the calling convention.  Let the
calling convention fit the language;  don't compromise the language to
adhere to some arbitrary calling convention.

Sean


 
 
 It need not return an implicit struct. A method may work directly on the
 result values, as if they were passed as parameters. For example, the
 following code:
 
 (int, double) MyMethod(int i, double d)
 {
     return (i * 2, d * 2);
 }
 
 int i;
 double d;
 
 i, d = MyMethod(10, 20.5);


So you want to change the comma operator ?
or will a,b be considered different if the first operation on the line

*foo(), b, c = a(); ?????

// foo() returns int* ; a() returns int,double,long;
Sep 21 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkkedv$das$1 digitaldaemon.com...

 Achilleas Margaritis wrote:

 It need not return an implicit struct. A method may work directly on the
 result values, as if they were passed as parameters. For example, the
 following code:

 (int, double) MyMethod(int i, double d)
 {
     return (i * 2, d * 2);
 }

 int i;
 double d;

 i, d = MyMethod(10, 20.5);


 So you want to change the comma operator ?
 or will a,b be considered different if the first operation on the line

 *foo(), b, c = a(); ?????

 // foo() returns int* ; a() returns int,double,long;


I wouldn't be against that, no.  What good is a comma operator that just
discards the values?  Why not keep the values and do something with them.

{ *(int* ir = foo()), double b, long c } = a();

You can leave off the names if you don't care about that value, and you can
specify them by name in any order if you know the names used as results from
a, you can map directly to them instead of relying on order.  Out parameters
could automatically be gathered up and made available in this way, but you'd
probably want to change the out parameter declaration in function
declaration to put all the out parameters together where the traditional
return value should be.

I still want to be able to overload operator_comma, of course.  ;)

Sean
Sep 22 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bkjj0m$2amj$1 digitaldaemon.com>, Achilleas Margaritis wrote:

 Return values could also have defaults:
 
 (int ri, double rd = 5) MyMethod(int i, double d)
 {
     ri = i * 2;
     rd = d * 2;
 }


How'd this be different from:

(int ri, double rd) MyMethod(int i, double d)
{
    rd = 5;
    ri = i * 2;
    rd = d * 2;
}

Default values are (in C++) part of the function's interface, I think,
and if the return values have them, it wouldn't be of much use to the
caller... Maybe if you inherit the default values from a base class or
something?

-Antti
Sep 21 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
This is how I picture data flow... pretty much a tuple as input and a tuple
as output.  You can name them and access them by name, though, which is a
bit different from how many languages treat tuples.

BTW functional languages like Haskell specify methods much like this.  But
due to currying they write them with each parameter separate.

    MyMethod :: int -> double -> (int, double)
    MyMethod i d = (i * 2, d * 2)

The default return value is a good idea.  But first we have to get named
return value(s) and maybe multiple return values by allowing an anonymous
struct declaration at the return type in the function declaration.

Sean


"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbms02o.vrp.jsykari pulu.hut.fi...

 In article <bkjj0m$2amj$1 digitaldaemon.com>, Achilleas Margaritis wrote:

 Return values could also have defaults:

 (int ri, double rd = 5) MyMethod(int i, double d)
 {
     ri = i * 2;
     rd = d * 2;
 }


 How'd this be different from:

 (int ri, double rd) MyMethod(int i, double d)
 {
     rd = 5;
     ri = i * 2;
     rd = d * 2;
 }

 Default values are (in C++) part of the function's interface, I think,
 and if the return values have them, it wouldn't be of much use to the
 caller... Maybe if you inherit the default values from a base class or
 something?

 -Antti
Sep 22 2003
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Sean L. Palmer wrote:

 I'm for multiple return values.  All it does it automate the process of
 declaring a custom struct to hold the values.  Good syntax sugar.
 
 Sean
 
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgn5f$310g$1 digitaldaemon.com...
 

Walter,

Maybe you've followed c.l.c.m enough recently to have noticed that there's
been a bit of a to-do about single return value, or not.

I was wondering how good the code generator is in this regard. In other
words, can we write for logic, and have more than one return value, as
appropriate, without worrying about ineffiencies. (Hint: my expectation is
that we can :) )


 
 
 


Possibly.  But consider a design where if you wanted to accept 
multiple returned parameters, you needed to enclose your list of 
receivers in parens, i.e.:
(a, b, c)  = multiRtrn(a, b, c)

(int v1, float v2, char[] v3) multiRtrn (int p1, float p2, char[] p3)
{	return	(p1, p2, p3);
}

Here in each case the comma operator is parsed the same way as in 
any other parameter list.  In fact, the whole thing could be 
re-written as a procedure:
void multiRtrn (in int v1, in float v2, in char[] v3, out int p1, 
out float p2, out char[] p3)
{  v1 = p1;  v2 = p2;  v3 = p3;  }

The tricky part would be, if you don't specify a certain number of 
receivers, everything after the last one you specify would be 
silently dropped.  This shouldn't be an error, because the reason 
for functions is that you want to be able to chain operations together.
Oct 08 2003