Re: [boost] Re: [MPL] Type detection

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-24 05:26:07

David B. Held <dheld_at_[hidden]> wrote:
> "Joel de Guzman" <joel_at_[hidden]> wrote in message
> news:005e01c399bf$be96e830$64646464_at_godzilla...
>> [...]
>> I'm writing some docs now. I posted some info regarding
>> Fusion here:
>> http://lists.boost.org/MailArchives/boost/msg53297.php
> 
> Believe it or not, I read that already (in the Fusion folder).
> I'm still not sure what a view is.  Is it an MPL sequence?  Is
> it a pair of iterators?  What can you do with it?  Why would
> you want one instead of a sequence?  I'm not sure what view
> in MPL is either, because the docs don't go into a lot of detail
> about that.

Views *are* sequences. Conceptually a view has a begin and end
(typically, but not always, an iterator pair).

Views, in Fusion are lighweight and can be passed around
inexpensively by value. You'll want to work with views because
you want to avoid the expensive transfer of data. Rather than 
working directly with tuples, the algorithms work with views and 
return views. 

Why are views important? For instance, imagine push_back-ing a 
tuple 10 times. If we work directly on tuples, we have something 
that will instantiate 10 tuples. Why? because, like MPL, and unlike
STL, we don't push_back tuples *in-place*. A new tuple will have to 
be returned by value. Example:

    tuple<T0, T1> 
    push_back(tuple<T0> const&, T1 const&);

    tuple<T0, T1, T2> 
    push_back(tuple<T0, T1> const&, T2 const&);

    ... more ...

Like MPL, and unlike STL, tuple algorithms are purely functional
and does not have side-effects. And, unlike MPL, tuples *have*
values. You are not dealing purely with types and constants.
Hence, lightweight views are more important in this domain. Let's 
see how push_back is implemented:

    template <typename Sequence, typename T>
    struct result_of_push_back
    {
        typedef joint_view<Sequence, single_view<T> > type;
    };

    template <typename Sequence, typename T>
    inline typename result_of_push_back<Sequence const, T>::type
    push_back(Sequence const& view, T const& x)
    {
        typedef joint_view<Sequence const, single_view<T> > result;
        single_view<T> val(x);
        return result(view, val);
    }

Notice that we are accepting a sequence and returning a view
(a reverse cons-list, if you look closer). The resulting view is lighweight
and can be passed around effortlessly. For example, you can push_back
many times without fear of unwanted heavy temporaries:

    push_back(push_back(push_back(t, "hello"), " world"), 123456) ...

Views become more important when we deal with more complex
algorithms and algorithm compositions where the output of one
algorithm is passed to the input of another.

>> template <typename T>
>> struct foo
>> {
>>     typedef typename as_sequence<T>::type my_types;
>>     typedef type_sequence<my_types> type_sequence;
>> 
>>     foo(void) : my_tuple(generate(type_sequence())) { }
>> 
>>     typename result_of_generate<type_sequence>::type my_tuple;
>> };
> 
> Good enough.  But when will it be ready? ;)

No promises, but soon. If you want pre- alpha code, the stuff in the
sandbox is a fully working prototype.

>> [...]
>> That and a lot more! Fusion is an entire MPL library for
>> tuples! If you know MPL, you'll love Fusion :-)
> 
> This disturbs me.  Why is MPL being rewritten for tuples?
> Can't tuples be used as an MPL sequence?  I'm sure this
> conversation has happened before, but if someone could
> summarize the issues, I'd appreciate it.

Why is MPL being rewritten for tuples? It's like asking the 
question why was STL rewritten for meta-sequences (MPL)?
Because these are two different domains. MPL deals with 
metafunctions, Fusion deals with polymorphic functions
and metafunctions. MPL deals with types and constants 
purely at compile time. Fusion deals with types constants
*and values* at compile time *and* at runtime. 

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net