Re: [boost] interest in 'tagged variant'? Useful in non-string spirit parsing.

From: Larry Evans (cppljevans_at_[hidden])
Date: 2007-12-09 14:14:21

On 12/06/07 11:26, Larry Evans wrote:
> On 12/05/07 21:23, Joel de Guzman wrote:
>> Larry Evans wrote:
> [snip]
>>> A prototype of such an extension is available in variant_tagged.zip
>>> here:
>>>
>>> http://www.boost-consulting.com/vault/index.php?&directory=Data%20Structures
>>>
>>> Use of the variant_tagged could be used whenever non-string processing
>>> is required in a spirit parser. 
[snip]

>> There's definitely interest in Spirit :-)
>> Thanks for your work on this. Very useful.

> However, I've thought about it some more and I think maybe the
> original variant with fusion::pair's as the template arguments
> would work as well and would avoid the duplication of the
> tag (variant::which() and variant_taggged:tag()).
A new version has been uploaded to vault which uses fusion::pair.
To facilitate this, a new fusion/support/intkey_val_pair_map.hpp
file containing like-named template was created.
What's interesting about this is that it seems that if
instead of boost::variant, fusion::map were used with the
intkey_val_pair_map as arg(maybe mpl::unpacked), then you'd
have a tuple with possibly "named"(or enumed) instead of
less meaningful unsigned indexes (i.e. args to get<>).
OTOH, if, instead of fusion::pair, mpl::pair were used, and then
the intkey_...map passed to mpl::map, then you have the mpl
map with "named" indices.

I'm looking for a generalization that can simplify the coding
of all the classes by defining a minimum number of templates
that can be combined to get the most general results.
Does that make sense?