[boost] tag::function -> tag::apply for consistency (was Re: [proto] design rationale for expr<proto::function, argsN<Fun, Args...> >?

From: Larry Evans (cppljevans_at_[hidden])
Date: 2008-03-23 11:33:26

On 03/22/08 22:18, Eric Niebler wrote:
> Steven Watanabe wrote:
>> AMDG
>>
>> Markus Werle wrote:
>>> Now we introduce another function call - not an operator 
>>> this time, but in C++ these are equivalent.
>>>
>>> struct fun_t {};
>>> terminal<fun_t>::type const fun = {{}};
>>>
>>> fun(a, b);
>>>
>>> This is represented by something similar to
>>>
>>> expr<
>>>   tag::function
>>>   ,args3<
>>>      ref_<expr<tag::terminal, args0<fun_tag> > const>
>>>     ,expr<tag::terminal, args0<> >
>>>     ,expr<tag::terminal, args0<> >
>>>     >
>>>  >
>>>
>>> This is suprising. In contrast to operator+, the function fun
>>> is treated as if it was an *operand*, not an *operator*.
>>> The expression is not tagged by _the_ function call, but by a 
>>> global this-is-a-function-tag and the function is stored in the
>>> argument typelist.
>>>   
>> I don't find it surprising.  This behavior is exactly what I would expect.
>>
>> fun(a, b) is equivalent to fun.operator()(a, b).  In a concept fun(int, int)
>> will be represented as
>>
>> concept Callable<class T> {
>>     void operator()(T, int, int);
>> };
>>
>> if I recall correctly.
> 
> Precisely. Another way to see this is to consider that the following 
> might be a valid expression within a domain:
> 
>    (a+b)(a-b);
> 
> That's equivalent to (a+b).operator()(a-b). Clearly, this needs to be 
> encoded as a binary tree with (a+b) as the left child and (a-b) as the 
> right, with tag::function.

In mpl, this is called apply instead of function.  Here:

boost-trunk/libs/mpl/doc/refmanual/apply.html

it appears as:

template<
       typename F, typename A1,... typename An
     >
struct applyn
{
     typedef unspecified type;
};

I think that using tag::apply instead of tag::function
would make proto more consistent with other boost
naming conventions, and also make it easier for
others (who were familiar with mpl apply) to see that it's not
surprising that "function fun is treated as if it were and *operand*".
I, at first kinda agreed with Markus' assessment; however, now I see
why it might be better as is.  If I'd seen apply instead of function,
this would have made the justification for the current form
easier to see.