Boost logo

Boost :

Subject: Re: [boost] [1.47] New libraries
From: Eric Niebler (eric_at_[hidden])
Date: 2011-03-17 09:34:31

On 3/17/2011 7:55 PM, Thomas Heller wrote:
> On Thu, Mar 17, 2011 at 1:33 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> OTOH, it would be very nice if Bind's placeholders were the same as
>> Phoenix's. So it would be worth taking the time to see if we could
>> refactor Proto such that terminals could be defined in a very
>> light-weight way. But I also know that Bind jumps through hoops of fire
>> with the placeholder definitions to support ancient compilers, so this
>> might not be possible.
> Right now, the placeholders defined in Boost.Bind can be used with
> just one little minor inconvience* inside Phoenix.
> *The problem is that Boost.Bind placeholders are not wrapped inside
> any proto terminal stuff or phoenix actor.
> This means that we can not except something like ::_1 + ::_2 to be
> seen as a phoenix expression.
> BUT:
> ::_1 + phoenix::placeholders::_2
> or
> phoenix::bind(::_1, ::_2)
> or
> phoenix::bind(::_1, phoenix::placeholders::_2)
> will work just fine!
> The same is true for the placeholders defined in BLL ... though i
> haven't checked if they specialize boost::is_placeholder.

Very cool.

>> However, if it /were/ possible (and we navigate the tricky proto-domain
>> waters), then I suggestion the placeholders be spun into their own
>> mini-library that can be shared across all the EDSLs in Boost that
>> require placeholders. (Except MPL, where the placeholders are types and
>> not objects.)
> Oh ... proto-domain waters *shiver* .... we need to investigate that
> topic very well ...
> This topic still needs very deep research ....
> Consider the above:
> ::_1 + phoenix::placeholders::_2

If we can't make these two one and the same (via a using declaration),
then there's no point. I'm hoping to avoid the ambiguous-_1-symbol
errors a few folks have complained about.

So, _1 would have to be in the phoenix domain, which is a subdomain of
the default domain, making it inherently weak wrt domain resolution. So

  ::_1 + 1

is a phoenix expression, but

  ::_1 >> spirit::qi::char_

is a spirit expression (assuming that spirit::qi::char_ is in a domain,
which I'm uncertain of, but the point remains). That all just works.
What we need to ensure is that phoenix::placeholder::_1 can be defined
without dragging in a whole lot of gunk. For instance, bind doesn't need
proto's operator overloads. We need *just* enough to define a terminal
in a domain. Nothing more. I think we can do this.

Certainly, older compilers cannot enter that brave new world, so on
those, the placeholders will have to stay separate.

Eric Niebler
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at