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 :) )

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 :) )

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)

"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

"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;
}

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;

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

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

"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

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.