Re: What are tuples exactly? (D's tuples considered harmful)

2011-02-25 Thread %u
>> 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.


Re: What are tuples exactly? (D's tuples considered harmful)

2011-02-25 Thread retard
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)

2011-02-25 Thread Jonathan M Davis
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)

2011-02-25 Thread Jesse Phillips
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)

2011-02-25 Thread Gary Whatmore
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)

2011-02-25 Thread Jesse Phillips
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.