Re: [boost] [local] Help for the Alternatives section

Subject: Re: [boost] [local] Help for the Alternatives section
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-05-02 12:55:57

On 02/05/2011 01:03, Lorenzo Caminiti wrote:
> On Sun, May 1, 2011 at 6:46 PM, Mathias Gaunard
> <mathias.gaunard_at_[hidden]>  wrote:
>> On 26/03/2011 23:19, Lorenzo Caminiti wrote:
>>>
>>> Hello all,
>>>
>>> I am updating Boost.Local docs and I could use a some help in getting
>>> the Alternatives section right
>>>
>>> http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html
>>
>> It's missing a few advantages of Boost.Phoenix-like approaches:
>
> I did try to list these aspects in the comparison table at the
> beginning of the Alternatives section. Please let me know if it is not
> clear enough.
>
>>   - can happen at the expression level and not just statement level. This
>> also means the function does not necessarily need to be named.
>
> This is captured under "Can be defined within expressions". I can add
> the function naming issue.

I must have been tired if I missed that, sorry.

>
>>   - does not require listing all variables to bind from the scope
>
> This is captured under "Bind variables in scope" that for Boost.Lambda
> reads "No (but variables in scope are accessible as usual within
> expressions)." and for Boost.Phoenix the same plus "Yes (using let
> which also allows to bind by constant reference)."

That's not what let is for.
let is to declare new variables local to the function [*]. All variables 
in scope are automatically caught as they're accessed with both 
Boost.Lambda and Boost.Phoenix.

It should be Yes for all cases here, and whether the library requires to 
user to explicitly list all variables or not should be made a separate 
point.

[*] The following Boost.Phoenix code:
auto f = let(_a = 42)[_a + _1]

is somewhat equivalent to

template<typename T>
auto f(T&& a1) -> decltype(42 + a1)
{
     auto _a = 42;
     return _a + std::forward<T>(a1);
}

>
>>   - can be quite more concise for simple tasks.
>
> I think this is arguable but I am providing code examples (actually of
> simple local functions) so users can judge on their own.

_1 + i

vs

int BOOST_LOCAL_FUNCTION(int a1, bind int i)
{
    return a1 + i;
}
BOOST_LOCAL_FUNCTION_NAME(foo);
foo

Clearly, Boost.Local is more verbose.

Boost.Phoenix is better for short and polymorphic stuff, Boost.Local is 
better for monomorphic, longer and more complex stuff that would be 
complicated to write with Phoenix.

>> There is also the polymorphism thing: functions generated by Boost.Local are
>> necessarily monomorphic, unlike Boost.Phoenix and global functors.
>
> Do you have a reference for this--like a WiKi page. I don't understand
> this topic and I'd need to study it more before adding to the docs.
> Thanks a lot.

Simply put, the function cannot take its arguments as template 
parameters, and also requires that the types of the arguments be specified.

You might want to know that I plan on proposing allowing template member 
functions in local classes for a future C++ standard TR (and polymorphic 
lambdas, too).
I think it is of utmost importance to be able to have polymorphic local 
functions.