Tuples with named attributes

[Bill Baxter]

Nathan Allan wrote:
> Has any consideration been given to the possibility of tuples with named 
> identified attributes, rather than ordinally identified attributes?  
> Named attributes are much more useful to humans, as is evidenced by the 
> fact that we use named rather than numbered identifiers in programming 
> languages.  In my view, tuples, as implemented in D, would be much more 
> useful with named attributes.
> 
> To illustrate my point, consider what a relation (table) type might look 
> like in D.  In the relational model of data, a relation is composed of n 
> tuples having the same named attributes.  This allows us to define the 
> relation type as a set of the name : type attribute definitions.  
> Imagine working with a database where the attributes of each relation 
> variable were numbered rather than named!
> 
> Number indexed tuples are much more difficult to grok than named ones.  
> A name indexed tuple can be easily understood to any developers as an 
> "anonymous struct".  Having helped design and use a language (D4) with 
> native support for tuples in their named form, I can attest to their 
> usefulness.   One example of their power is as an orthogonal means to 
> return multiple results from a function.  Rather than a bizarre mixture 
> of return values and output parameters, a set of named values can be 
> easily returned.
> 
> In D4 you can do stuff like this:
> 
> var name := GetName();
> ...name.First...
> ...name.Last...
> 
> there are also join, rename, and extend/project operators included with 
> the language:
> 
> GetName() { First FirstName /* rename */, First.ToUpper() UpperFirst /* 
> extend */ } join GetAddress()
> /* result is a tuple (called a row in D4) with FirstName, UpperFirst, 
> and address attributes) */
> 
> ...highly recommended!
> 
> Regards,
> 
> -- 
> Nathan Allan

I haven't heard that suggestion specifically, but I and some others have 
campaigned for named keyword arguments in the past, and tuples and 
argument lists go hand-in-hand.  If you have named argument-lists it 
makes sense to have named tuples, and vice versa.

We were never able to get Walter very excited about it, though.

You can always do the Lisp thing and create 'alists'.  That is, 
alternate Tuple!("name", value, "othername", othervalue).  Then write 
helper functions to manipulate them.  Tuple's flattening behavior makes 
it kind of limited though.  So you really probably need the struct-tuple 
trick, something like:

struct STuple(T...)
{
    alias T list;
}

Then use
   Tuple!("name", STuple!(value), "othername", STuple!(othervalue)
The struct prevents flattening.

I definitely like the idea though.  There's already things like 
AStruct.tupleof to go from struct to tuple, but the equivalence is 
incomplete because you lose the names in the struct.  I would love to 
see some sort of Utopian grand unification between structs, tuples, and 
parameter lists.

--bb