Re: [boost] [proto] design rationale for expr<proto::function, argsN<Fun, Args...> >?

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-22 23:18:27

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.

To see a real-world example that uses operator() this way, see:
http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/examples/map_assign.html

It's an implementation of the map_list_of() function from the 
Boost.Assign library. It lets you initialize a map as follows:

     // Initialize a map:
     std::map<std::string, int> op =
         map_list_of
             ("<",1)
             ("<=",2)
             (">",3)
             (">=",4)
             ("=",5)
             ("<>",6)
         ;

>> What fun means is context dependent, I would expect the context
>> to take care about what fun_t might mean, so if we want 
>> symmetry first I'd expect a type representation similar to
>>
>> expr<
>>   tag::function<fun_t> 
>>   ,args2<
>>     ,expr<tag::terminal, args0<...ommitted...> >
>>     ,expr<tag::terminal, args0<...ommitted...> >
>>     >
>>  >
>>
>>
>> So I wonder whether this asymmetry was introduced due to the
>> fact that function objects could have a state which makes them
>> an in-between between operator and operand ...
>>   
> 
> IMO, a function object is not an operator at all.  The operator
> involved is the function call operator which takes a reference to
> the function object (*this) as the first parameter.  I don't see this
> as being any more asymmetric than any other member function call.

Right, it's perfectly symmetric with all the other operators.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com