Re: [boost] phoenix::bind

Subject: Re: [boost] phoenix::bind
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-10-02 09:31:12

Giovanni Piero Deretta wrote:
> On Thu, Oct 2, 2008 at 1:10 PM, Joel de Guzman

> OK, I'm really really missing something:
> 
> #include <iostream>
> #include <vector>
> #include <boost/spirit/include/phoenix_core.hpp>
> #include <boost/spirit/home/phoenix/stl.hpp>
> #include <boost/spirit/include/phoenix_operator.hpp>
> 
> 
> using namespace boost::phoenix;
> 
> struct foo {
>     typedef void result_type;
>     void operator()(int x) const{
>         std::cout << x << std::endl;
>     }
> };
> 
> namespace px = boost::phoenix;
> 
> int
> main()
> {
>     std::vector<int> r(10, 1);
>     foo f;
>     px::for_each(px::arg_names::arg1, f)(r);
>     return 0;
> 
> }
> 
> This compiles just fine and prints 1 ten times....
> I do not need bind to use 'f', it is a perfectly fine unary function
> object. Phoenix has no business messing with it :)

Aha! You've just uncovered an undocumented feature that
I was working on. In phoenix1 and in an experimental
version of the scopes, this is actually valid:

     for_each(_1, val(f))(r);

Phx always captures by value, so f is essentially val(f)
and val(f)() *is* the f itself. Notice the extra nullary
function application.

(aside: I'm actually surprised that this feature got in.
Some tests by Dan Marsden even takes advantage of it).

:-) You must be smiling now imagining me slapping
my head! :-)

>>> I understand the difference, but what buys us? What is the advantage?
>>> It feels a bit like an internal detail leaking...
>> Ask Jaakko. It's his interface. I can't speak for him.
>> I'm only saying that it is not the same and you can't replace
>> the one for the other. I'm also saying that it is the "protect"
>> model that Phoenix is adopting, not unlambda. Hence, the
>> misconception and misunderstanding.
>>
> 
> Yes, and that is what I'm lobbying to change :)

I hear ya. But if you just be patient and try to read my plans
on pxh.lambda that initiated this discussion more carefully,
I actually have something that somehow unifies all these
(including the undocumented val(f) you got rolling).

Listen, I'm not saying that what you are saying is wrong. I'm
just saying that that is not the (current) design.

Finally, I'm very eager to hear Jaakko's take on this. More
inputs, the better.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net