www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What are tuples exactly? (D's tuples considered harmful)

reply Morlan <home valentimex.com> writes:
While trying to understand the expand mechanism presented in the TDPL book I
tried to read std.typetuple and std.typecons files. I found a true nightmare
in those files in the form of an almost infinite chain of aliases and macro
processing. How can one understand a written text if the words are redifined
in every other line? And people say that goto instruction is bad? Please give
me a break.

Anyway, at some point I realized that I cannot understand what is going on
because there is some language mechanism in action which I do not know. I
wrote a small program to confirm this. Here it is:

struct S { TypeTuple!(int, double) field; }
void main(){
	S mys;
	mys.field[0] = 4;
	mys.field[1] = 4.4;
}

It compiles all right. But if you replace the S's definition with {int, double
field;}
it does not compile. So tuples are clearly much more than a sequence of types
and they trigger a completely different semantic action than a plain sequence
of types. Is there a precise definition of tuples somewhere?
Feb 25 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Morlan Wrote:


 While trying to understand the expand mechanism presented in the TDPL book I
 tried to read std.typetuple and std.typecons files. I found a true nightmare
 in those files in the form of an almost infinite chain of aliases and macro
 processing. How can one understand a written text if the words are redifined
 in every other line? And people say that goto instruction is bad? Please give
 me a break.


The aliases serve to simplify things. You would find it even more overwhelming
if the true types were used. Aliases should show their base type in the
documentation though.


 Anyway, at some point I realized that I cannot understand what is going on
 because there is some language mechanism in action which I do not know. I
 wrote a small program to confirm this. Here it is:
 
 struct S { TypeTuple!(int, double) field; }
 void main(){
 	S mys;
 	mys.field[0] = 4;
 	mys.field[1] = 4.4;
 }
 
 It compiles all right. But if you replace the S's definition with {int, double
 field;}
 it does not compile. So tuples are clearly much more than a sequence of types
 and they trigger a completely different semantic action than a plain sequence
 of types. Is there a precise definition of tuples somewhere?


 struct S { int, double field; }

Right, tuples have very little syntactic sugar. And frankly this wouldn't be
the syntax I would want.

I don't think there is any good introduction to D tuples. The best way to think
of them is to know they are compile time constructs. They are their purely to
be manipulated during compilation and have no meaning at runtime. These types
are made possible because of language features like templates, mixins, and
alias parameters.

Another issue is that D isn't very strict. We have TypeTuple and Tuple, both of
which can contain types and values. But it doesn't look like things will be
changing.
Feb 25 2011
parent %u <wfunction hotmail.com> writes:
 Anyway, at some point I realized that I cannot understand what is going on
because there is some language mechanism in action




which I do not know.


 Fuck no! "precise definition of tuples" is something that always makes me
really grumpy. Do we want a incomprehensible ivory tower


language or something practical? The D's tuples are a bit hazy. A bit harder to
grok, but the good sides are better performance,
flexibility and friendliness towards pragmatic c/c++ mentality. If you want
something "better", go use Haskell an enjoy your 90%
slower runtimes.

Lol.
I think I'll try to explain tuples, since I feel kind of bad just taking from
the community but not giving back. :) So here's an
explanation for those who are new to the concept:

--------------

The word "tuple" is used with two _very_ different meanings in D: compile-time
tuples and run-time tuples. So let's split them up.


- Run-time tuples are located in std.typecons, and are pretty much C++
templates that let you create a data type called a "Tuple".
That's it. Aside from the fact that you can actually specify the field names,
there's no more to them than their equivalents in C++
(0x). So Tuple!(int, "a", long, "b") is just a shorthand way of making a data
type that bundles two int's and long's together, and
it names the fields "a" and "b'. Pretty simple.


- Compile-time tuples are a COMPLETELY different beast. They don't require any
external modules (they're purely a compile-time
feature), although std.typetuple is useful when working with them.
You can think of a tuple as "a bunch of things separated by commas". These
"things" can be types, numbers, strings, or aliases
(which refer to other things).

The declaration of std.typetuple.TypeTuple is actually pretty straightforard,
but it takes a bit of getting used to:

	template TypeTuple(T...)
	{
	    alias T TypeTuple;
	}

What exactly does this do? It creates a template with any number of "things" as
arguments, then gives them the name TypeTuple as a
whole. To see what I mean, look at this code:

	foreach (T; TypeTuple!(int, bool, string))
	{
		writeln(T.init);
	}

This code iterates through every parameter given to TypeTuple -- namely, it
iterates through the types int, bool, and string --
making T represent the parameter, and it generates code for the inside of the
loop, just like a regular for loop would.

Except that this code is generated AT COMPILE TIME!

Contrary to its, name, a TypeTuple can actually be a tuple of any "thing" --
you can also give it strings, numbers, etc. So you
could also do something like:

	foreach (V; TypeTuple!(0, false, "Hello"))
	{
		writeln(V);
	}

and it would print just what you expect.


You can make a function called myWriteLine, which prints everything but the
first and last parameters:

	void myWriteLine(T...)(T items)
	{
		writeln(items[1 .. $ - 1]);  //1 is the first index you want, "$ - 1" is the
last index you DON'T want
	}

This powerful idea is extended in a variety of ways, and it ultimately lets you
generate a lot of code at compile-time that you
would find difficult or impossible to generate in other languages, or that, if
possible, would otherwise happen at runtime. It's
truly a beast, and I've barely shown any of its power here. :)



Hope that helped.
Feb 25 2011
prev sibling next sibling parent reply Gary Whatmore <no spam.sp> writes:
Jesse Phillips Wrote:


 Morlan Wrote:
 

 While trying to understand the expand mechanism presented in the TDPL book I
 tried to read std.typetuple and std.typecons files. I found a true nightmare
 in those files in the form of an almost infinite chain of aliases and macro
 processing. How can one understand a written text if the words are redifined
 in every other line? And people say that goto instruction is bad? Please give
 me a break.


 
 The aliases serve to simplify things. You would find it even more overwhelming
if the true types were used. Aliases should show their base type in the
documentation though.
 

 Anyway, at some point I realized that I cannot understand what is going on
 because there is some language mechanism in action which I do not know. I
 wrote a small program to confirm this. Here it is:
 
 struct S { TypeTuple!(int, double) field; }
 void main(){
 	S mys;
 	mys.field[0] = 4;
 	mys.field[1] = 4.4;
 }
 
 It compiles all right. But if you replace the S's definition with {int, double
 field;}
 it does not compile. So tuples are clearly much more than a sequence of types
 and they trigger a completely different semantic action than a plain sequence
 of types. Is there a precise definition of tuples somewhere?


 
  struct S { int, double field; }
 
 Right, tuples have very little syntactic sugar. And frankly this wouldn't be
the syntax I would want.
 
 I don't think there is any good introduction to D tuples. The best way to
think of them is to know they are compile time constructs. They are their
purely to be manipulated during compilation and have no meaning at runtime.
These types are made possible because of language features like templates,
mixins, and alias parameters.
 
 Another issue is that D isn't very strict. We have TypeTuple and Tuple, both
of which can contain types and values. But it doesn't look like things will be
changing.


Fuck no! "precise definition of tuples" is something that always makes me
really grumpy. Do we want a incomprehensible ivory tower language or something
practical? The D's tuples are a bit hazy. A bit harder to grok, but the good
sides are better performance, flexibility and friendliness towards pragmatic
c/c++ mentality. If you want something "better", go use Haskell an enjoy your
90% slower runtimes.

People always complain about missing documentation, but I don't care. Better
developers don't need documentation, they value the tools. Walter spends 95%
time on developing tools, 5% helping the community in this newsgroup and in
conferences.
Feb 25 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Gary Whatmore Wrote:


 Fuck no! "precise definition of tuples" is something that always makes me
really grumpy. Do we want a incomprehensible ivory tower language or something
practical? The D's tuples are a bit hazy. A bit harder to grok, but the good
sides are better performance, flexibility and friendliness towards pragmatic
c/c++ mentality. If you want something "better", go use Haskell an enjoy your
90% slower runtimes.


What is this? "There is no place for improvement because it works." "We don't
need documentation because someone who is dedicated to using D can figure it
out."

Why do we even have D in the first place? Tuples are a mess, we don't have a
better solution yet, but that doesn't mean we should stop looking.
Feb 25 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 25, 2011 03:39:31 Morlan wrote:

 While trying to understand the expand mechanism presented in the TDPL book
 I tried to read std.typetuple and std.typecons files. I found a true
 nightmare in those files in the form of an almost infinite chain of
 aliases and macro processing. How can one understand a written text if the
 words are redifined in every other line? And people say that goto
 instruction is bad? Please give me a break.
 
 Anyway, at some point I realized that I cannot understand what is going on
 because there is some language mechanism in action which I do not know. I
 wrote a small program to confirm this. Here it is:
 
 struct S { TypeTuple!(int, double) field; }
 void main(){
 	S mys;
 	mys.field[0] = 4;
 	mys.field[1] = 4.4;
 }
 
 It compiles all right. But if you replace the S's definition with {int,
 double field;}
 it does not compile. So tuples are clearly much more than a sequence of
 types and they trigger a completely different semantic action than a plain
 sequence of types. Is there a precise definition of tuples somewhere?


If all you want is a normal tuple, use Tuple from std.typecons. It even has the 
convenience function tuple for creating them. TypeTuple is a different beast 
entirely, and you probably don't want that unless you specifically need it. It 
has to do with processing types and are _not_ generally what you want. If what 
you're looking for is tuples, then use std.typecons.Tuple.

- Jonathan M Davis
Feb 25 2011
parent retard <re tard.com.invalid> writes:
Fri, 25 Feb 2011 12:18:11 -0800, Jonathan M Davis wrote:


 On Friday, February 25, 2011 03:39:31 Morlan wrote:

 While trying to understand the expand mechanism presented in the TDPL
 book I tried to read std.typetuple and std.typecons files. I found a
 true nightmare in those files in the form of an almost infinite chain
 of aliases and macro processing. How can one understand a written text
 if the words are redifined in every other line? And people say that
 goto instruction is bad? Please give me a break.
 
 Anyway, at some point I realized that I cannot understand what is going
 on because there is some language mechanism in action which I do not
 know. I wrote a small program to confirm this. Here it is:
 
 struct S { TypeTuple!(int, double) field; } void main(){
 	S mys;
 	mys.field[0] = 4;
 	mys.field[1] = 4.4;
 }
 
 It compiles all right. But if you replace the S's definition with {int,
 double field;}
 it does not compile. So tuples are clearly much more than a sequence of
 types and they trigger a completely different semantic action than a
 plain sequence of types. Is there a precise definition of tuples
 somewhere?


 
 If all you want is a normal tuple, use Tuple from std.typecons. It even
 has the convenience function tuple for creating them. TypeTuple is a
 different beast entirely, and you probably don't want that unless you
 specifically need it. It has to do with processing types and are _not_
 generally what you want. If what you're looking for is tuples, then use
 std.typecons.Tuple.


I've used:

template Tuple(T...) { alias T Tuple; }

Nicely built-in and works in most cases.
Feb 25 2011