Re: [boost] [1.47] New libraries

Subject: Re: [boost] [1.47] New libraries
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-03-17 08:55:31

On Thu, Mar 17, 2011 at 1:33 PM, Eric Niebler <eric_at_[hidden]> wrote:
> On 3/17/2011 6:17 PM, Joel de Guzman wrote:
>> On 3/17/11 5:24 PM, Daniel James wrote:
>>> On 17 March 2011 08:52, Thomas Heller<thom.heller_at_[hidden]> Â wrote:
>>>>
>>>> There are still some unresolved issues. Mainly how to deal  with the
>>>> migration of Boost.Bind, Boost.Lambda and Phoenix V2. There hasn't
>>>> been any discussion regarding that.
>>>
>>> I don't think it'd be a good idea to do anything to bind or lambda in
>>> this release. Was there a consensus on replacing them? Personally, I'd
>>> like to keep the existing Boost.Bind, even if in a different
>>> namespace. I appreciate its relative simplicity and portability.
>>
>> Bind should not be touched. People rely on Bind esp. those using old
>> compilers. Also, Bind is extremely lightweight with almost zero
>> dependencies. Phoenix cannot get anywhere near that.
>
> Joel is right. The best we can do is make phoenix::bind a drop-in
> replacement and let people choose.
>
> 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.

> 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 ::_1 (magically, somehow) belongs to something like bind_domain and
phoenix::placeholders::_2 to phoenix_domain. It is not clear in which
domain the resulting expression will be, and not clear how to handle
the resulting expression.
Three cases:
1) phoenix_domain is the super domain of bind_domain:
Ok, no problem here, the resulting expression will be in
phoenix_domain and we can evaluate without problems in phoenix.
However, what is the scenario for other libraries that feel the need
to reuse ::_1 ...

2) The common domain of phoenix_domain and bind_domain is proto::default_domain:
The resulting expression is in neither domain and we have lost the
ability to evaluate the resulting expression in the bind_domain sense
or in the phoenix_domain sense.

3) The common domain of phoenix_domain and bind_domain is proto::not_a_domain:
The expression will be not valid. Problem solved, somehow ;)