View mode: basic / threaded / horizontal-split · Log in · Help
October 07, 2010
Tuple literal syntax
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
Re: Tuple literal syntax
Don't function arguments also comprise a tuple? A tuple of 1.
October 07, 2010
Re: Tuple literal syntax
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
Re: Tuple literal syntax
Kagamin wrote:
> Don't function arguments also comprise a tuple? A tuple of 1.

Yes, but that's not ambiguous.
October 07, 2010
Re: Tuple literal syntax
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
Re: Tuple literal syntax
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
Re: Tuple literal syntax
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
Re: Tuple literal syntax
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
Re: Tuple literal syntax
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
Re: Tuple literal syntax
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