Boost logo

Boost Users :

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-01-19 20:02:39


Sohail Somani wrote:
> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 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

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net