I currently think it's a good idea to unify structs and parameter lists, and tuples are basically anonymous structs with anonymous fields (only way to get values back out is by pattern matching on types)

What is a parameter list anyhow but a shape of a collection of values at some point in the flow of execution.  On the way into a function is a valid point in the flow of execution.  So is the return, or should be.

A way to flexibly map structs to structs, or tuples to tuples, or tuples to structs, would make this sort of thing very convenient.

I think D is aiming more toward status quo remaining largely C compatible.

Sean

"Commander Odama" <Commander_member@pathlink.com> wrote in message news:bqu23r$1io7$1@digitaldaemon.com...
> With structs but you have the advantage of selecting whatever value you
want
> from a returned struct.
>
> With multiple returns you have to consider all of the return values. There is a slight advantage to a packaged multiple return.  This allows you to package a set of values for return and keep the syntax simpler.
You can
> select out of the return bundle whatever value you want.
>
> The Java designers were very oversighted in removing structs.  Without
structs
> and without multiple returns there is no way to include or substitute
multiple
> returns.  So structs are useful without multiple return.

Sean L. Palmer wrote:
> I currently think it's a good idea to unify structs and parameter lists, and
> tuples are basically anonymous structs with anonymous fields (only way to
> get values back out is by pattern matching on types)

This would requiere big changes in the language. Let the fields rather be named alphabetivally in their order: a,b,c,... This gives us 26 fields, which is usually quite enough - everything larger than 5 is better advised being a struct. I'm not sure Further fields are requiered, but then they could be named aa, ab, ac, ... zz. :) Also array indexing operator could be used as a notation for indexing fields by ordinal.

This would in turn requiere a type inference assignment operator, which is a useful beast all by itself, and work in the cases where the current normal compiler can figure out the type of right hand side expression.

instaed of :

MyObjectType a = new MyObjectType(blahblah);

you could write:

a := new MyObjectType.

for a function which returns multiple values:

ret := FSinCos();

An unnamed strauct corresponding to type of ret would need to be implicitly declared just before use:

struct trowaway_blahblah {real a; real b;}

And the declaration of FSinCos should be:

(real, real) FSinCos (real a);

I believe this also reuieres that we change semantics of the comma operator, which would then return a tuple, instead of only the last value. This would nontheless allow the most common use of comma operator in C, which is to stuff up more into the for loop declaration.

One possible problem is that this could make declaration of a tuple of tuples problematic...

> What is a parameter list anyhow but a shape of a collection of values at
> some point in the flow of execution.  On the way into a function is a valid
> point in the flow of execution.  So is the return, or should be.

True.

> A way to flexibly map structs to structs, or tuples to tuples, or tuples to
> structs, would make this sort of thing very convenient.

Sounds complicated.

> I think D is aiming more toward status quo remaining largely C compatible.

Hm... Who needs the curent comma operator anyway?

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqve80$nk9$1@digitaldaemon.com...
> Sean L. Palmer wrote:
> > I currently think it's a good idea to unify structs and parameter lists,
and
> > tuples are basically anonymous structs with anonymous fields (only way
to
> > get values back out is by pattern matching on types)
>
> This would requiere big changes in the language. Let the fields rather be named alphabetivally in their order: a,b,c,... This gives us 26 fields, which is usually quite enough - everything larger than 5 is better advised being a struct. I'm not sure Further fields are requiered, but then they could be named aa, ab, ac, ... zz. :) Also array indexing operator could be used as a notation for indexing fields by ordinal.

As I said, D probably won't go for it.  Your idea of using a thru z for the names isn't bad at all.

> This would in turn requiere a type inference assignment operator, which is a useful beast all by itself, and work in the cases where the current normal compiler can figure out the type of right hand side expression.
>
> instaed of :
>
> MyObjectType a = new MyObjectType(blahblah);
>
> you could write:
>
> a := new MyObjectType.
>
> for a function which returns multiple values:
>
> ret := FSinCos();
>
> An unnamed strauct corresponding to type of ret would need to be implicitly declared just before use:
>
> struct trowaway_blahblah {real a; real b;}
>
> And the declaration of FSinCos should be:
>
> (real, real) FSinCos (real a);

But if you do give the return values names, it would be more self-documenting and robust against later changes, say adding new return values or rearranging them.

> I believe this also reuieres that we change semantics of the comma operator, which would then return a tuple, instead of only the last value. This would nontheless allow the most common use of comma operator in C, which is to stuff up more into the for loop declaration.

I doubt that will happen.  ;(

> > A way to flexibly map structs to structs, or tuples to tuples, or tuples
to
> > structs, would make this sort of thing very convenient.
>
> Sounds complicated.

Haskell has something like this, where you can create a new data structure based on the contents of some other one, but providing overrides for some of the values.

struct point
{
    float x,y;
}

struct size
{
    float width,height;
}

point mypoint;
size distancetoorigin = mypoint { width = x, height = y };

Something like that, but the above syntax is not good.

> > I think D is aiming more toward status quo remaining largely C
compatible.
>
> Hm... Who needs the curent comma operator anyway?

Nobody.  It has very few uses, and those are questionable:

Comma Operator Use 1:   putting more than one assignment into a statement controlled by an if without having to use curly braces:

if (foo > bar)
    x = foo, y = bar;

which can easily be written thusly, no big deal:

if (foo > bar)
{ x = foo; y = bar; }

Comma Operator Use 2:  doing some calculation before return

int fn()
{
    int x,y;
    return x = get_x(), y = get_y(), x*x + y*y + 1;
}

It would be clearer if written like this anyway:

int fn()
{
    int x = get_x();
    int y = get_y();
    return x*x + y*y + 1;
}

Comma Operator Use 3:  for loops

for (int i = 0, j = 1; i < 10 && j != i; ++i, j = i*3)
    printf("i = %d, j = %d\n", i, j);

One could argue that this for loop is trying to do too much anyway.  But the language could easily be extended in a slightly different way:  allow statement blocks anywhere a statement is allowed, even in the 3rd section of a for loop:

for (int i = 0, j = 1; i < 10 && j != i; { ++i; j = i*3; })
    printf("i = %d, j = %d\n", i, j);

That's a bad example because ++i, j = i*3 could be written j = ++i*3;

Anyway the point is, there is not much the comma operator can do that can't easily be expressed some other, more legible way.  It would be nice to have comma operator available for something truly useful, like tuples.

Sean

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:br036k$1lis$1@digitaldaemon.com...
>
> Anyway the point is, there is not much the comma operator can do that
can't
> easily be expressed some other, more legible way.  It would be nice to
have
> comma operator available for something truly useful, like tuples.
>
> Sean
>
>


Indeed...   I've only used the comma operator in for loops, and that was only in a dubious effort to save space.

Tuples would be a much better use of the syntax, IMHO.

Dan

In article <br036k$1lis$1@digitaldaemon.com>, Sean L. Palmer says...
>
>"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqve80$nk9$1@digitaldaemon.com...
>> Sean L. Palmer wrote:
>> > I currently think it's a good idea to unify structs and parameter lists,
>and
>> > tuples are basically anonymous structs with anonymous fields (only way
>to
>> > get values back out is by pattern matching on types)
>>
>> This would requiere big changes in the language. Let the fields rather be named alphabetivally in their order: a,b,c,... This gives us 26 fields, which is usually quite enough - everything larger than 5 is better advised being a struct. I'm not sure Further fields are requiered, but then they could be named aa, ab, ac, ... zz. :) Also array indexing operator could be used as a notation for indexing fields by ordinal.
>
>As I said, D probably won't go for it.  Your idea of using a thru z for the names isn't bad at all.
>
>> This would in turn requiere a type inference assignment operator, which is a useful beast all by itself, and work in the cases where the current normal compiler can figure out the type of right hand side expression.
>>
>> instaed of :
>>
>> MyObjectType a = new MyObjectType(blahblah);
>>
>> you could write:
>>
>> a := new MyObjectType.
>>
>> for a function which returns multiple values:
>>
>> ret := FSinCos();
>>
>> An unnamed strauct corresponding to type of ret would need to be implicitly declared just before use:
>>
>> struct trowaway_blahblah {real a; real b;}
>>
>> And the declaration of FSinCos should be:
>>
>> (real, real) FSinCos (real a);
>
>But if you do give the return values names, it would be more self-documenting and robust against later changes, say adding new return values or rearranging them.
>
>> I believe this also reuieres that we change semantics of the comma operator, which would then return a tuple, instead of only the last value. This would nontheless allow the most common use of comma operator in C, which is to stuff up more into the for loop declaration.
>
>I doubt that will happen.  ;(
>
>> > A way to flexibly map structs to structs, or tuples to tuples, or tuples
>to
>> > structs, would make this sort of thing very convenient.
>>
>> Sounds complicated.
>
>Haskell has something like this, where you can create a new data structure based on the contents of some other one, but providing overrides for some of the values.
>
>struct point
>{
>    float x,y;
>}
>
>struct size
>{
>    float width,height;
>}
>
>point mypoint;
>size distancetoorigin = mypoint { width = x, height = y };
>
>Something like that, but the above syntax is not good.
>
>> > I think D is aiming more toward status quo remaining largely C
>compatible.
>>
>> Hm... Who needs the curent comma operator anyway?
>
>Nobody.  It has very few uses, and those are questionable:
>
>Comma Operator Use 1:   putting more than one assignment into a statement controlled by an if without having to use curly braces:
>
>if (foo > bar)
>    x = foo, y = bar;
>
>which can easily be written thusly, no big deal:
>
>if (foo > bar)
>{ x = foo; y = bar; }
>

Also note that if tuples are entities on their own, then they can be both L-values and R-values of an assignment.  So you could write.

if (foo > bar)
(x,y) = (foo,bar) ;



>Comma Operator Use 2:  doing some calculation before return
>
>int fn()
>{
>    int x,y;
>    return x = get_x(), y = get_y(), x*x + y*y + 1;
>}
>
>It would be clearer if written like this anyway:
>
>int fn()
>{
>    int x = get_x();
>    int y = get_y();
>    return x*x + y*y + 1;
>}
>

Or you could write it with tuples:

int fn()
{
(int x, int y)  = ( get_x(), get_y() ) ;
return x*x + y*y + 1;
}

..or better yet...

int fn()
{
(int x, int y)  = get_x_and_y() ;
return x*x + y*y + 1;
}

>Comma Operator Use 3:  for loops
>
>for (int i = 0, j = 1; i < 10 && j != i; ++i, j = i*3)
>    printf("i = %d, j = %d\n", i, j);
>
>One could argue that this for loop is trying to do too much anyway.  But the language could easily be extended in a slightly different way:  allow statement blocks anywhere a statement is allowed, even in the 3rd section of a for loop:
>
>for (int i = 0, j = 1; i < 10 && j != i; { ++i; j = i*3; })
>    printf("i = %d, j = %d\n", i, j);
>
>That's a bad example because ++i, j = i*3 could be written j = ++i*3;
>

Or using tuples...

for ( (int i, int j) = (0, 1) ; i < 10 && j != i ; (i,j) = ( i+1, (i+1)*3 ) )
printf("i = %d, j = %d\n", i, j);

>Anyway the point is, there is not much the comma operator can do that can't easily be expressed some other, more legible way.  It would be nice to have comma operator available for something truly useful, like tuples.
>
>Sean
>
>

>>(x, y) = (r*cos(theta), r*sin(theta)) ;

>>/* which is more compact than.. */
>>x = r*cos(theta) ;
>>y = r*sin(theta)  ;

While it may be a few keystrokes more compact it's hardly easier to read or comprehend. Many moons ago I learned programming in APL where the "Butch" programmers did as much as possible in a single line (And in APL it's quite amazing what you can do in a single line of 15-20 characters) However it always ended up as mostly unreadable/unmaintainable. Software changes constantly and language "features" that get in the way of clarity and simnplicity should be avoided as they end up increasing costs of development and decreasing time to market. And that's what makes or breaks projects and companies. (Unless you've been through the rise and fall of a few companies that's not so obvious.)

-- 
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com

What's good for MATLAB is not necessarily good for D. These are two VERY different languages with different problem domains, and users. I've lived through some REALLY long debug sessions where someone used a language feature to save a couple of bytes of source code space instead of making it clear and simple to understand.

A struct or class makes more sense as the returned values are all related together in some way or they wouldn't be returned from the same function.

-- 
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com

There are two different issues being discussed in this thread, the first is multiple return values, the second is the idea of tuples.  The example which you cite below is an example of the use of tuples.  As such it is used to highlight the proposed syntax of tuple assignment.  Furthermore, programmers can write bad code with or without tuples.  The semicolon can be used to "Butch" code (as you say), e.g.

x = r*cos(theta) ; y = r*sin(theta)  ;

There are may who have opined that the introduction of tuples would enhance the utility of the language.

It is my belief that high-level languages should allow you to compactly express your *intentions* in a non-ambiguous way to the compiler.  If there is a frequently encountered coding pattern which can be reduced and simplified through the introduction of a new language feature, then the benefits of such a feature should be carefully considered.

It is not that tuples are in and of them selves are of that much utility that they should be added to the language, however, by introducing tuples as a language feature, multiple return values are a natural consequence.  The best case which I have seen for tuples is the code to swap two variables, e.g.

(x, y) = (y, x) ;  /* simple, clear, concise */

other useful applications for tupples would be calculations which naturally linked as such as coordinate conversion

(r, theta) = ( sqrt(x*x + y*y) , atan2(y,x) ) ;

the real power of the tuple comes in multiple return values, e.g.

(r, theta) = toPolar(x, y) ;

...or...

(year, month, day, dayofweek) = getDate() ;

...or...

(hours, min, sec) = getTime() ;

Note that to get the date or time information, phobos returns a string ( toDateString() or toTimeString ) which must be parsed to retrieve the proper information.  This IMO is a "poor man's" way of doing multiple returns in C. D should do better.

Thank you,

Mark.

P.S. Merry Christmas.



"Steve Maillet" <nospam1@EntelechyConsulting.com> wrote in message news:bsg80r$2s5v$1@digitaldaemon.com...
> >>(x, y) = (r*cos(theta), r*sin(theta)) ;
>
> >>/* which is more compact than.. */
> >>x = r*cos(theta) ;
> >>y = r*sin(theta)  ;
>
> While it may be a few keystrokes more compact it's hardly easier to read
or
> comprehend. Many moons ago I learned programming in APL where the "Butch" programmers did as much as possible in a single line (And in APL it's
quite
> amazing what you can do in a single line of 15-20 characters) However it always ended up as mostly unreadable/unmaintainable. Software changes constantly and language "features" that get in the way of clarity and simnplicity should be avoided as they end up increasing costs of
development
> and decreasing time to market. And that's what makes or breaks projects
and
> companies. (Unless you've been through the rise and fall of a few
companies
> that's not so obvious.)
>
> -- 
> Steve Maillet (eMVP)
> Entelechy Consulting
> smaillet_AT_EntelechyConsulting_DOT_com
>
>

"Steve Maillet" <nospam1@EntelechyConsulting.com> wrote in message news:bsg8f3$2t06$1@digitaldaemon.com...
> What's good for MATLAB is not necessarily good for D. These are two VERY different languages with different problem domains, and users.

Agreed!

> I've lived
> through some REALLY long debug sessions where someone used a language
> feature to save a couple of bytes of source code space instead of making
it
> clear and simple to understand.
>

Some language features can be used with great power by some and abused to great extremes by others.  This says more about the programmer than it does about the feature. (it is unfortunate that there are many books which encourage the abuse of language features, especially C books.)

> A struct or class makes more sense as the returned values are all related together in some way or they wouldn't be returned from the same function.
>

Not true.  If a structure's only purpose is to return multiple values, then IMO it complicates an interface rather than simplifies it because a temporary instance must be created to shuffle out of the function.

> -- 
> Steve Maillet (eMVP)
> Entelechy Consulting
> smaillet_AT_EntelechyConsulting_DOT_com
>
>

Finally,  I think that the reason that functions only return one value has more to do with mathematics than with computer science.  The name is borrowed from the familiar mathematical concept we all learned in Algebra, Trig, Calc, for example, log(x), tan(y), sin(z), etc.  The reality is that most of the mathematical functions which are handled in these courses are "single valued" meaning that they map to the real numbers.  Occasionally we studied functions which take complex values.  Similarly on the parameter side, we often encounter single parameters in our math classes.  For some reason, when the computer scientists borrowed the concept, they extended and generalized the parameters to be multiple valued, but, in general, did not extend the return values in the same way.  The reason for this IMO (this is pure speculation) is that in math class we were all taught that "functions are single valued" meaning that each point in the domain must map to *only one* point in the range.  Mathematical functions, however, are defined as a mapping from the domain to the range where each element in the range may very well be an aggregate of simpler objects, or multiple valued.

Having said this, I think multiple return vales would be logical generalization of the borrowed concept of a function just as multiple parameters were.

Mark.

>A struct or class makes more sense as the returned values are all related together in some way or they wouldn't be returned from the same function.

so all of your functions only have one parameter as well? because this makes more sence then as well. and if multiple parameters are needed, you pass them as struct, right?