interest in 'tagged variant'? Useful in non-string spirit parsing.
A recent thread in spirit.general NG suggested to me the need for a 'tagged variant' extension to boost::variant in order to emulate the tagged-union mentioned in this post in the thread: http://article.gmane.org/gmane.comp.parsers.spirit.general/12611 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. Each tag in the using corresponds to a token-id and each value associated with that token-id is the attribute for that token-id. This closely emulates the way yacc does it, IIRC, except it just uses a union and the tag is somehow "implicit". Is there any interest in using this in spirit or boost in general?
Larry Evans wrote:
A recent thread in spirit.general NG suggested to me the need for a 'tagged variant' extension to boost::variant in order to emulate the tagged-union mentioned in this post in the thread:
http://article.gmane.org/gmane.comp.parsers.spirit.general/12611
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. Each tag in the using corresponds to a token-id and each value associated with that token-id is the attribute for that token-id. This closely emulates the way yacc does it, IIRC, except it just uses a union and the tag is somehow "implicit".
Is there any interest in using this in spirit or boost in general?
There's definitely interest in Spirit :-) Thanks for your work on this. Very useful. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
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. Each tag in the using corresponds to a token-id and each value associated with that token-id is the attribute for that token-id. This closely emulates the way yacc does it, IIRC, except it just uses a union and the tag is somehow "implicit".
Is there any interest in using this in spirit or boost in general?
There's definitely interest in Spirit :-) Thanks for your work on this. Very useful. Thanks for the feedback. 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()).
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?
Larry Evans wrote:
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?
Hi Larry, Pardon the delay in replying. Yeah, this makes perfect sense. Are there docs yet? Would you be interested in having it hosted in spirit2/support ? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 12/17/07 16:29, Joel de Guzman wrote:
Larry Evans wrote:
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?
Hi Larry, Pardon the delay in replying. Yeah, this makes perfect sense. Are there docs yet? Would you be interested in having it hosted in spirit2/support ?
Yes, however, I'm still thinking. One thing that bothered me about using boost::variant was it had to be adapted to behave like a tagged variant. Wouldn't it be better to use a "bare-bones" real tagged variant. I'm assuming that then this could be adapted to behave like the existing boost::variant. Why? Well, it seems that boost::variant is a restriction on such a tagged variant and a restriction is sorta like a derived class restricting a super. After all, a super cannot be converted to a derived, but a derived can be converted to a super; therefore, the derived is a more specific instance (i.e. a restriction) of the super. Anyhow, all this reasoning led me back to the aligned_types mentioned in a May 07 post:
http://archives.free.net.ph/message/20070514.193240.ada2f1bb.en.html
I've since been working on a non-variadic version of it, which I just uploaded to vault: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=aligned_types.zip&directory=Data%20Structures&PHPSESSID=0998fe36863986f6bb6517b804771c4e Of course this just defines the aligned_storage (and offsets, in case of tuples); however, it should be easy to create a tagged_variant from aligned_types<composite_kinds::variant,Sequence>::type.
participants (2)
-
Joel de Guzman -
Larry Evans