[boost] Re: Small tuple extension

From: Joel (joel_at_[hidden])
Date: 2005-04-26 17:21:59

Larry Evans wrote:
> On 04/26/2005 10:30 AM, Giovanni Piero Deretta wrote:
> 
>> On 4/26/05, Larry Evans <cppljevans_at_[hidden]> wrote:
>>
> [snip]
> 
>> Anyway, the get<type> form is most useful with tuples containing
>> elements of different type.  In practice you overload the meaning of
>> the type to also be a an element tag.  This way tuples  become as
> 
> 
> But isn't an enumerator in some enumeration the equivalent of
> an "element tag"?
> 
>> powerful as structures: you can access element by  "name".  They are
> 
> 
> The enumerator can also be thought of as a name.
> 
>> more powerful actually, as they have introspection capability: 
>> elements can be enumerated. Also the possibility of accessing tuple
>> elements indipendently of the exact tuple type and element position
>> can be very handy in generic programming.
> 
> 
> Which can be done with enumerators also.
> 
>>
>> The get<type> form that i proposed can be easily added with zero
>> changes to the existing tuple code/interface.
>> A more complex addition would allow the association of a tag to each
>> tuple element i.e.:
>> tuple<mpl::list<element1_type, element1_tag>, mpl::list<element2_type,
>> element2_tag>,.....>
>> a get<elementn_tag> would return the nth element.  This would make the
>> tag unique and maybe open new possibilities.
> 
> 
> But again, I don't see why adding a tag is any better than using an
> enumerator.  The only difference between an array (all elements of
> the same type) and a tuple, is that the type of the value as well
> as the value depends on the index.  And if the types are indexed
> by the same enumeration, then you've solve the problem.  In addition,
> a similar scheme can be used for variants (or disjoint sum).  See
> 
> http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/indexed_types/test/sum.cpp?view=markup 
> 
> 
>>
>> BTW, tuples containing many objects of the same type are better seen
>> as containers, thus the indexed get is fine.
> 
> 
> Agreed, but the indexed get works just as well when the argument is
> an enumerator instead of a literal unsigned, and when it's an
> enumerator, the meaning is clearer:
> 
>     t.get<0>();
>     t.get<1>();
> 
> is obviously not as clear as:
> 
>     t.get<first_field>();
>     t.get<second_field>();
> 
> [snip]
> 
>> In a theoretical extended_tuple, the enum could be part of the tuple
>> itself, so you could do 'get<my_tuple.element1> (my_tuple)' and there
>> would not be no name conflict.  The problem with enums is that you
>> have to maintain them separately: this is information duplication that
>> could easily go out of sync.
> 
> 
> Not if you use either something like mpl's map:

[...]

>  >-------------------- cut here ---------------------
> or use a specialization of a template indexed by the
> enumeration, as shown in the boost-sandbox sum.cpp
> file mentioned above or in another test file, product.cpp,
> in the same location.
> 
> I'm not sure which is better.

Gentlemen, these are all variations of the associative tuple.
An implementation of fusion's set and map will be available
as soon as I formalize the interface. I already have an
implementation handy, ready to be deployed.

Yes, associative tuples are powerful structures. They could
potentially simplify code such as those in phoenix lambda,
let scopes and the named parameters.

As to which is better: a (type) tag or an enumerator; a (type)
tag is definitely better because 1) an enumerator fails to
address common idioms like named parameters which uses type
tags. And, 2) a type tag can handle enumerators as well if you
place them in some sort of enum_<enum> template akin to
mpl::int_:

     template <my_enum e>
     struct my_enum_ {};

IOTW, you can easily convert an enum to a type.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net