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

Subject: Re: [Boost-users] [FunctionTypes] function_arity for non-built-ins
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-01-06 18:26:36

On 1/6/2011 4:00 PM, Larry Evans wrote:
> 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.

I am aware of fc++ library. Is not Phoenix supposed to be a replacement 
of most of the concepts in fc++ ? But Phoenix after years and years has 
still not been released as a Boost library for whatever reason. So I do 
not know if list comprehension or monads are part of Phoenix. I know 
what list comprehensions are from Python but I have never looked at 
monads or know for what they are useful.

>
> 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.

It sounds like that essentially you are attempting to rewrite areas of 
boost.mpl using variadic templates. Are you adding new functionality to 
the mpl that is useful ?

>
> 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.

That would be spectacular. Anthing to help debugging template code 
and/or help with understanding compiler error messages is always most 
welcome by me.

>
>> 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.

My understanding of variadic templates is that it also could make some 
end-user interfaces much easier syntactically to use.

>
>> 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.

I appreciate your intent but I think you must be realistic that if you 
do not document at least the differences between what you are doing and 
what the current mpl is doing, nobody is going to want to study the 
source code just to see how it might be beneficial.

>
> 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.

Thanks for the explanations, especially about variant which I do know.

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

Thanks for telling me about your library. At the worst I will look at it 
to understand better how to use variadic templates for some of my own 
work. I think variadic templates offer a good potential for certain 
programming idioms. Unfortunately still very few compilers support it so 
unless one is strictly targeting the few compiler/versions that do one 
has to also write templates without it.

I apologize for partially hijacking this thread.