• Nathan Allan (33/33) Jun 18 2007 Has any consideration been given to the possibility of tuples with named...
• Bill Baxter (24/67) Jun 18 2007 I haven't heard that suggestion specifically, but I and some others have...

"Nathan Allan" <nathan alphora.com> writes:

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 

Bill Baxter <dnewsgroup billbaxter.com> writes:

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