Re: [boost] [1.47] New libraries

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
<snip>

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
http://www.boostpro.com