The point is, however, that you don't know that the concatenation will produce a tuple when you call your APPEND_COMMA. If it does not and just produces an identifier of the form IDENTIFIER_XXX then your APPEND_COMMA(IDENTIFIER_XXX SQUARE) will end up as 'APPEND_COMMA_I IDENTIFIER_XXX SQUARE' which you do not want.
Yes, of course, you will need to check that you have an identifier first.
Actually I realized that the comma is not be needed at all in Paul's IDENTIFIER macros above. There is already code in VMD that can split a sequence beginning with a tuple into the beginning tuple and the rest of the sequence ( BOOST_VMD_TUPLE ). So the logic of parsing for an identifier at the beginning of a sequence is to start by looking for a beginning tuple in the sequence, if not found test for an identifier through concatenation, and if the subsequent sequence after concatenation now starts with a beginning tuple, the code can separate the beginning tuple from the remainder of the sequence and extract the v-identifier.
Yes, there is similiar logic in the `STRING_TOKEN` macro I showed, except my code doesn't handle custom namespaces(ie `STRING_`) nor multiple namespaces.
Sorry I can't follow this or udnerstand what you are doing. I don't know what BOOST_PP_AUTO_REC does even when I look at its code <g>.
Well the macro is auto reentrant. So it has a macro for each recursion level up to 16(ie `MSVC_INVOKE_1`, `MSVC_INVOKE_2`, etc). The `BOOST_PP_AUTO_REC` then will search for a macro that can be called(it hasn't been painted blue). It does this by calling the `DETAIL_MSVC_INVOKE_P` predicate. Then `DETAIL_MSVC_INVOKE_P` wil pass in nullary parenthesis into `MSVC_INVOKE`, and if that result isn't nullary then it means that recursion level got painted blue. So the `BOOST_PP_AUTO_REC` will do a binary search and try to find the first predicate that is true. It will return that recursion level, which it will concat with `MSVC_INVOKE_` so the correct macro will be called. Does that make sense? Perhaps Paul can explain it better than me.
You might find this expansion easier with VMD. With Paul's suggestion and my realization that the final comma is not needed, I will be reprogramming the VMD v-sequence macros so that you should be able to take a v-sequence, like your 'string' of 'from(x, numbers) where(x < 3) select(x * x)' and break it down into its constituent v-types without the limitations current VMD incurs. In fact I intend to add a VMD macro, something like BOOT_VMD_SEQUENCE(vsequence) which will return all the v-types in some way ( probably a tuple, seq, or just variadic data, I have yet to decide ).
Of course for my case, I don't need to know what category or type it is(it may be useful for other people). So having it as a sequence like I've shown is very useful. Also, I was thinking it might be useful to have some kind of `BELONGS_TO` to query which namespace a token belong to. Paul Fultz II -- View this message in context: http://boost.2283326.n4.nabble.com/vmd-Library-Review-tp4667522p4667569.html Sent from the Boost - Dev mailing list archive at Nabble.com.