Re: [Boost-users] [FunctionTypes] function_arity for non-built-ins

Subject: Re: [Boost-users] [FunctionTypes] function_arity for non-built-ins
From: Larry Evans (cppljevans_at_[hidden])
Date: 2011-01-06 16:00:14

On 01/06/11 12:51, Edward Diener wrote:
> On 1/6/2011 12:32 PM, Larry Evans wrote:
>> On 01/06/11 08:48, Roman Perepelitsa wrote:
>>> 2011/1/6 Hossein Haeri<powerprogman_at_[hidden]
>>> <mailto:powerprogman_at_[hidden]>>
>>>
>>>      Hi Roman,
>>>
>>>      >  This is actually possible in most cases. Check this nice article
>>>      by Eric
>>>      >  Niebler:
>>>
>>>
http://www.boost.org/doc/libs/1_45_0/doc/html/proto/appendices.html#boost_proto.appendices.implementation.function_arity
>>>
>>>
>>>      This is beautiful, thanks! :) So, from the description, it seems
>>>      like this can_be_called guy (or its siblings) is in heavy use for
>>>      Proto. Does Proto then also port this as a part of its toolbox? Or,
>>>      is it only for internal use and I'll need to craft my own
>>> version of it?
>>>
>>>
>>> Unfortunately, there's no official boost implementation of
>>> can_be_called. You'll have to roll your own version.
>>>
>>
>> Eric's code was used as a basis for a variadic templates implementation
>> of can_be_called which is available here:
>>
>>
>>
http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/function_types/can_be_called.hpp
>>
>>
>> A use is shown here:
>>
>>
>>
http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/composite_storage/pack/multiple_dispatch/apply_unpack.hpp
>>
>
> Are you still working on the variadic templates sandbox project ?

Yes.

> What is the project meant to do ?

Originally, it was meant to just see if variadic templates
could be used in a rewrite of mpl.  Since then, I've been
trying various other things, such as the multiple_dispatch
code.  I'd like to eventually see if the code can't be used
as a springboard to using monads and list comprehension,
like in the fc++ library:

  http://sourceforge.net/projects/fcpp/

but, again, using variadic templates.

Also, I'd like to see if something like the DeBruijn indices method,
mentioned here:

  http://lists.boost.org/Archives/boost/2010/09/171123.php

could be used to solve some problems I had in mpl, which *may* be
related to name clashes since mpl uses _1 for the 1st formal arg of
any Lambda Expression.  However, there's another method, call HOAS
(Higer Order Abstract Syntax) to avoid the same problem:

  http://www.cse.unsw.edu.au/~chak/haskell/term-conv/

So, I may decide to grok that before I decide how to do thing.

In addition, several haskell papers mention using monads to provide a
trace facility for language interpreters.  For example:

  http://www.cs.yale.edu/~liang-sheng/popl95.ps.gz

I thought maybe such a trace facility, translated to c++, would help
debugging template metaprograms.

> It looks like you are using variadic templates for various Boost
> libraries.

Yes.  I'm also thinking it could be used for spirit or proto or
something akin to those.  I know Christopher is working on variadic
template fusion; so, I probably won't try that one.

> I am interested in using variadic templates in a sandbox project in
> which I am working, so I was interested when I saw your variadic
> templates library, but there was no explanation or documentation there.

The variadic mpl library is almost one-to-one with the original mpl;
hence, I was hoping the docs for the original would suffice.  The
major difference is sometimes changing the order of the arguments to
satisfy the variadic template compiler constraint that packs only
occur at the end or the template argument list.

Now as far as composite_storage is concerned, I was hoping that just
looking at the code and test drivers would make it apparent how it
differs from boost::fusion containers and boost::variant.  Basically,

  * For tuple-like containers:

    the only difference between:

        fusion::vector
          < T1
          , T2
          ...
          ,Tn
          >

      and:

        composite_storage::pack::container
          < all_of_aligned
          , mpl::integral_c<Enumeration,E_0>
          , T1
          , T2
          ...
          , Tn
          >

      is the use of Enumeration literals instead of unsigned literals
      to access the elements *and* the use of c.project<E_i>() instead
      of at_c<i>(c), for some container c, to retrieve the i-th
      element where, if c is from composite storage, then:

        enum Enumeration
        { E_0
        , E_1
        ...
        , E_n
        };

  * For variant-like containers:

    There's a more substantial difference. For:

      boost::variant
        < T1
        , T2
        ...
        , Tn
        > bv;

    bv defaults to T1.  In addition, changing the contained type just
    requires an assigment:

      bv = T2();

    OTOH, for:

      boost::composite_storage::pack::container
        < one_of_maybe
        , mpl::integral_c<Enumeration,E_0>
        , T1
        , T2
        ...
        , Tn
        > cv;

    the user must explicity state which type is to be stored:

      cv.inject<E_2>(T2());

    The reason for this difference is that it's more in line with the
    way mathematicians express the operation.  In addition, it's more
    in line with the way unix yacc treats its tokens.  For example,
    any token in yacc has an explicit tag, and this is just how
    one_of_maybe works.

Hope that explains things more and why it's taking me so long to get
things more documented.

  -regards,
  Larry