On 10/7/10 11:11 CDT, kenji hara wrote: > 2010/10/7 bearophile<bearophileh...@lycos.com>: >> Another design decision is if tuples have a nominative or structural type, >> this problem comes out in this bug report: >> http://d.puremagic.com/issues/show_bug.cgi?id=4128 > >> Another significant problem is about naming things, currently the situation >> is a mess: >> http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html >> http://d.puremagic.com/issues/show_bug.cgi?id=4113 >> In the end I have suggested to name "record" the typecons tuples, and >> "tuple" the typetuples. > > On these issues, I'm almost agreed with bearophile > > I think we may not use 'Tuple' as 'a structure packed values'. > It is more better that 'Tuple' should *only* use as mixing sequence > types and values.
The problem with this is that it departs from nomenclature that is agreed by everyone else, which is provincial. First off, a tuple IS agreed to be an ordered collection of heterogeneous items. Google reveals copious evidence, both in math and programming language theory. Benjamin Pierce's "Types and programming languages", a book that all PL students sleep with under their pillow, defines tuples in section 11.7 (entitled "Tuples") like D does. The first paragraph: "It is easy to generalize the binary products of the previous section to n-ary products, often called tuples. For example, {1,2,true} is a 3-tuple containing two numbers and a Boolean. Its type is written {Nat,Nat,Bool}." The following section defines records as tuples with labeled fields. I don't think it's a crime that D calls both tuples. We could define Record just to be more Catholic than the Pope, but I don't see a necessity there. At any rate, "Tuple" is correct, known, understood, and accepted. D's built in type tuples (those used with TypeTuple) are weird. They are an artifact of the language that has no meaning outside it. Such tuples are defined as "anything that could be a template parameter", which really ties them to various language design decisions. My suggestion is that we deprecate TypeTuple and we call it AliasTuple because that's really what it is - it's a tuple of stuff that can be passed in as an alias parameter. > My proposals are: > 1. We should name definitions of structures. > - "Structure that all of fields have name" shuld be called 'Struct'. > - "Structure that some of fields have name" shuld be called 'Odd struct'. > - "Structure that none of fields have name" shuld be called 'Record'. > > Struct∈Odd struct∈Record > > 2. We remove field namming funcion from std.typecons.tuple, and rename > it to Record. > > 3. We rename std.typetuple.TypeTuple to Tuple. > > -------- > pseudo codes: > > auto a = Record!(int, int)(10, 20); This is not a record by Pierce. > auto b = Struct!(int, "x", int, "y")(100, 200); This is a record by Pierce. > auto c = OddStruct!(int, "x", int)(15, 25); We could reject this during compilation if needed. I don't see anything confusing grouping the above under "Tuple". Andrei