October 07, 2010
There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html

http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html

A lot of it foundered on what the syntax for tuple literals should be. The top of the list is simply enclosing them in ( ). The problem with this is

 (expression)

Is that a parenthesized expression, or a tuple? This really matters, since (e)[0] means very different things for the two. Finally, I got to thinking, why not just make it a special case:


 ( ) == tuple
 (a) == parenthesized expression
 (a,b) == tuple
 (a,b,c) == tuple
 (a,b,c,d) == tuple

etc.

No ambiguities! Only one special case. I submit this special case is rare, because who wants to define a function that returns a tuple of 1? Such will come about from generative programming, but:

(a,b,c)[0]

may be how the generative programming works, and that suggests:

(a,0)[0]

as how a user could generate a tuple of 1. Awkward, sure, but like I said, I think this would be rare.
October 07, 2010
Don't function arguments also comprise a tuple? A tuple of 1.
October 07, 2010
On Wednesday 06 October 2010 23:04:35 Walter Bright wrote:
> There have been a couple of looong threads about tuples:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_peopl e_using_D_93528.html
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operat or_be_removed_in_D2_101321.html
> 
> A lot of it foundered on what the syntax for tuple literals should be. The top of the list is simply enclosing them in ( ). The problem with this is
> 
>   (expression)
> 
> Is that a parenthesized expression, or a tuple? This really matters, since (e)[0] means very different things for the two. Finally, I got to thinking, why not just make it a special case:
> 
> 
>   ( ) == tuple
>   (a) == parenthesized expression
>   (a,b) == tuple
>   (a,b,c) == tuple
>   (a,b,c,d) == tuple
> 
> etc.
> 
> No ambiguities! Only one special case. I submit this special case is rare, because who wants to define a function that returns a tuple of 1? Such will come about from generative programming, but:
> 
> (a,b,c)[0]
> 
> may be how the generative programming works, and that suggests:
> 
> (a,0)[0]
> 
> as how a user could generate a tuple of 1. Awkward, sure, but like I said, I think this would be rare.

As long as you can define () to use tuples in an unambiguous manner, I'm all for it. Personally, I don't really mind Tuple so much as I find the fact that you have both Tuple and TypeTuple to be highly confusing. But it wouldn't hurt my feelings to just use parens either.

- Jonathan M Davis
October 07, 2010
Kagamin wrote:
> Don't function arguments also comprise a tuple? A tuple of 1.

Yes, but that's not ambiguous.
October 07, 2010
On Wed, 06 Oct 2010 23:04:35 -0700, Walter Bright <newshound2@digitalmars.com> wrote:
> (a,0)[0]




> as how a user could generate a tuple of 1. Awkward, sure, but like 
I said, I 
> think this would be rare.

Python uses:

(5,) 

Which is a lot better IMHO
October 07, 2010
On Thu, 07 Oct 2010 10:04:35 +0400, Walter Bright <newshound2@digitalmars.com> wrote:

> There have been a couple of looong threads about tuples:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html
>
> A lot of it foundered on what the syntax for tuple literals should be. The top of the list is simply enclosing them in ( ). The problem with this is
>
>   (expression)
>
> Is that a parenthesized expression, or a tuple? This really matters, since (e)[0] means very different things for the two. Finally, I got to thinking, why not just make it a special case:
>
>
>   ( ) == tuple
>   (a) == parenthesized expression
>   (a,b) == tuple
>   (a,b,c) == tuple
>   (a,b,c,d) == tuple
>
> etc.
>
> No ambiguities! Only one special case. I submit this special case is rare, because who wants to define a function that returns a tuple of 1? Such will come about from generative programming, but:
>
> (a,b,c)[0]
>
> may be how the generative programming works, and that suggests:
>
> (a,0)[0]
>
> as how a user could generate a tuple of 1. Awkward, sure, but like I said, I think this would be rare.

If tuples become first-class citizens of D lands, is it possible to make 'void' and alias to an empty tuple? I believe they are basically the same thing. A function that accepts no arguments may be defined as a function that accepts a tuple of size 0:

void f1(string, string);
auto tuple1 = ("hello, %s", "world");

f1(tuple1); // works

void f2();
auto tuple2 = ();
f2(tuple2); // should work, too

That would allow creation a variables of type void, which is very useful for generic programming. Here is an example:

auto proxy(alias f)()
{
    auto result = f();
    do(stuff);
    return result;
}

Works for any functions 'f' but returning voids.

I know it have been asked many times with no success, but still...
October 07, 2010
Juanjo Alvarez wrote:
> On Wed, 06 Oct 2010 23:04:35 -0700, Walter Bright <newshound2@digitalmars.com> wrote:
>> (a,0)[0]
> 
> 
> 
> 
>> as how a user could generate a tuple of 1. Awkward, sure, but like 
> I said, I
>> think this would be rare.
> 
> Python uses:
> 
> (5,)
> Which is a lot better IMHO

I agree, that would fit well with the optional trailing commas in array literals.
October 07, 2010
On 10/7/10 1:04 CDT, Walter Bright wrote:
> There have been a couple of looong threads about tuples:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html
>
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html
>
>
> A lot of it foundered on what the syntax for tuple literals should be.
> The top of the list is simply enclosing them in ( ). The problem with
> this is
>
> (expression)
>
> Is that a parenthesized expression, or a tuple? This really matters,
> since (e)[0] means very different things for the two. Finally, I got to
> thinking, why not just make it a special case:
>
>
> ( ) == tuple
> (a) == parenthesized expression
> (a,b) == tuple
> (a,b,c) == tuple
> (a,b,c,d) == tuple
>
> etc.
>
> No ambiguities! Only one special case. I submit this special case is
> rare, because who wants to define a function that returns a tuple of 1?
> Such will come about from generative programming, but:
>
> (a,b,c)[0]
>
> may be how the generative programming works, and that suggests:
>
> (a,0)[0]
>
> as how a user could generate a tuple of 1. Awkward, sure, but like I
> said, I think this would be rare.

Sorry for being Debbie Downer in this thread, but I'm not seeing a lot of progress here. This is nothing but a syntax cutesy that helps Tuple!(A, B) and tuple(a, b) and leaves all other issues related to tuples unresolved (I'm actually afraid that it exacerbates them).

One good thing about Tuple is that it allows names of fields, so functions can return tuples with conveniently named fields, e.g. Tuple!(bool, "found", size_t, "position") etc. without having to define little structs everywhere and fostering simple, clear code on the caller side.

Also, obviously, empty tuples and tuples with one element are self-explanatory (Tuple!() and Tuple!(int) for types, tuple() and tuple(4) for values).

Up until recently the syntax t[i] didn't work for tuples, forcing t.field[i]. This marginally improves usage of tuples. There are still other issues left due to compiler bugs; for example slicing t[a .. b] is supposed to work but it doesn't. But my question is, do we need more notation, more special cases, more ambiguities, more solution to ambiguities, more corner cases (there's already a request for handling void in a particular way)...? And for what? Quite literally because we refuse to call a tuple a tuple? I'm not seeing much gain here. Syntactic sugar is good in moderate quantities, but in Perlis' words this is bound to cause cancer of the semicolon.

My suggestion on improving tuples is to fix the compiler bugs that currently hamstrung Tuple and to make it the best it can be. Once we're clear on the functionality, it would be great to see how we can package it better with a bit of language support.


Andrei
October 07, 2010
Thu, 07 Oct 2010 03:20:23 -0500, Andrei Alexandrescu wrote:

> Sorry for being Debbie Downer in this thread, but I'm not seeing a lot
> of progress here. This is nothing but a syntax cutesy that helps
> Tuple!(A, B) and tuple(a, b) and leaves all other issues related to
> tuples unresolved (I'm actually afraid that it exacerbates them).
> 
> One good thing about Tuple is that it allows names of fields, so functions can return tuples with conveniently named fields, e.g. Tuple!(bool, "found", size_t, "position") etc. without having to define little structs everywhere and fostering simple, clear code on the caller side.

Why do tuple fields need a name? Isn't this a new ad-hoc way to introduce structural typing in D? I often start with tuples, but if it turns out that the value is used in many places, it will be eventually replaced with a struct (e.g. coordinates in a gui / gamedev) for better type safety. Even with structs the need for field names is very rare. The real need for tuples is in very special cases where the syntax needs to be light.
October 07, 2010
retard Wrote:

> safety. Even with structs the need for field names is very rare. The real need for tuples is in very special cases where the syntax needs to be light.

You really need tuples to write obscure functional code.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home