• Gary Whatmore <no spam.sp> Feb 25 2011
• Jesse Phillips <jessekphillips+D gmail.com> Feb 25 2011

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.

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.