Sohail Somani wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Tobias Schwinger
Sohail Somani wrote:
If I am trying to make a fusion sequence mpl compatible, do I need to specialize mpl::is_sequence as well?
No. mpl::is_sequence just checks whether mpl::begin returns mpl::void_ (in this case it's not an MPL Sequence).
--------------
Thank you for your reply. If I do what you suggest (include intrinsic/mpl), it still doesn't compile. I checked fusion::result_of::begin<myseq>::type was correct but mpl::begin<type>::type is still void_. I'm sure I'm doing something wrong, but I can't figure out what!
The example you attached did fail to compile with an incomplete type message.
The semantics of mpl::is_sequence is: typedef not_< is_same< begin<T>::type,void_ > >::type c; That would be true for adapted fusion sequences if you include at least: #include <boost/fusion/sequence/intrinsic/mpl/begin.hpp> or, as Tobias suggested: #include <boost/fusion/sequence/intrinsic/mpl.hpp> which brings in all of them. <----------------> I'm not entirely sure, but my analysis is that: I think that the problem in your case is that mpl::begin<T> relies on proper mpl tag dispatching through mpl::sequence_tag<T>. For native fusion sequences, this would do the right thing. For adapted sequences, this is most probably not doing the right thing. Try to see if specializing that to return fusion::fusion_sequence_tag will solve the problem. If it does, then we'll think of a way to accommodate that in the equation. The basic question here is: should an adapted fusion sequence automatically be an mpl::sequence. The answer, as of now is "no". That can easily change, however, since fusion already has the right facilities to make it so. Yet, this issue needs more deliberation and thought, but my initial reaction is that the answer should be "yes". Having said that, I should point out that there should also be a way to disable this automatic fusion->mpl adaptation. There are cases where the fusion mpl intrinsics give the wrong (or inefficient) behavior. Eric (Niebler) pointed me to one such case (I'm CC'ing Eric). I think now that the solution to this issue is to (again) specialize mpl::sequence_tag<T> to not return fusion::fusion_sequence_tag and do the dispatching of mpl intrinsics manually. Again, this is just my quick analysis. I haven't done any code experiments to support my theories. Perhaps others are wiser than I am or have more time to look into this can prove me wrong. Nevertheless, I'll note this and add it in my todo list. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net