What are tuples exactly? (D's tuples considered harmful)
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?
Re: What are tuples exactly? (D's tuples considered harmful)
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.
Re: What are tuples exactly? (D's tuples considered harmful)
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.
Re: What are tuples exactly? (D's tuples considered harmful)
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.
Re: What are tuples exactly? (D's tuples considered harmful)
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
Re: What are tuples exactly? (D's tuples considered harmful)
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.
Re: What are tuples exactly? (D's tuples considered harmful)
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.
