Hello, I'd like to ask if it is possible to make Boost.Lambda place holders _1, _2 and _3 compatible with Boost.Bind? The reason I ask is that I often use both these libraries which makes it impossible to import lambda's namespace into global and forces me to use some shorthand namespace aliases, like bll or lambda. On the other hand, as a user I don't see much difference between ::_1 and boost::lambda::_1. I think, if lambda used bind's placeholders it would gain usability. -- Best regards, Andrey mailto:andysem@mail.ru
Andrey Semashev wrote:
Hello,
I'd like to ask if it is possible to make Boost.Lambda place holders _1, _2 and _3 compatible with Boost.Bind?
The reason I ask is that I often use both these libraries which makes it impossible to import lambda's namespace into global and forces me to use some shorthand namespace aliases, like bll or lambda. On the other hand, as a user I don't see much difference between ::_1 and boost::lambda::_1. I think, if lambda used bind's placeholders it would gain usability.
If there are no technical reasons not to, I agree this would be nice. And IMO they should be Proto terminals, so that libraries like Spirit and xpressive can use them seamlessly. template<typename I> placeholder { typedef I type }; proto::terminal<placeholder<mpl::int_<0> > >::type const _1 = {{}}; proto::terminal<placeholder<mpl::int_<1> > >::type const _2 = {{}}; ... I'm not sure how well legacy compilers will fare with Proto, though. FWIW, the lambda library is to be replaced with Joel de Guzman's Phoenix library, and there is a nascent effort to port Phoenix to Proto. (I'm leaving today for a week-long vacation. I'll be on email only off and on.) -- Eric Niebler Boost Consulting www.boost-consulting.com
On 4/7/07, Eric Niebler <eric@boost-consulting.com> wrote:
FWIW, the lambda library is to be replaced with Joel de Guzman's Phoenix library
Will this happen soon (i.e. Boost 1.35 or 1.36)? I'm wondering what pertinence this has to the recent discussion about lambda compatibility with result_of. If Boost.Lambda is no longer going to be around after it is replaced by Phoenix, perhaps the issue of lambda/result_of compatibility is moot. Daniel
Daniel Walker wrote:
On 4/7/07, Eric Niebler <eric@boost-consulting.com> wrote:
FWIW, the lambda library is to be replaced with Joel de Guzman's Phoenix library
Will this happen soon (i.e. Boost 1.35 or 1.36)? I'm wondering what pertinence this has to the recent discussion about lambda compatibility with result_of. If Boost.Lambda is no longer going to be around after it is replaced by Phoenix, perhaps the issue of lambda/result_of compatibility is moot.
I think it's more accurate to say that it will be merged. This plan has been going on for ages now. Fusion and Spirit2 development took all my time. Anyway, I am hopeful that something happens sooner rather than later. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Andrey Semashev wrote:
Hello,
I'd like to ask if it is possible to make Boost.Lambda place holders _1, _2 and _3 compatible with Boost.Bind?
The latest version of Bind supports arbitrary placeholders via the TR1-compatible is_placeholder<> trait/metafunction. See libs/bind/test/bind_placeholder_test.cpp for an example.
Peter Dimov wrote:
Andrey Semashev wrote:
Hello,
I'd like to ask if it is possible to make Boost.Lambda place holders _1, _2 and _3 compatible with Boost.Bind?
The latest version of Bind supports arbitrary placeholders via the TR1-compatible is_placeholder<> trait/metafunction. See libs/bind/test/bind_placeholder_test.cpp for an example.
I was going to add that now we just have to specialize is_placeholder for Lambda's placeholders, but closer investigation on my part revealed that someone going by the nickname of 'pdimov' already did that 9 months ago: http://boost.cvs.sourceforge.net/boost/boost/boost/lambda/detail/lambda_functors.hpp?r1=1.7&r2=1.8 :-)
Hello Peter, Monday, April 9, 2007, 8:17:14 PM, you wrote:
Peter Dimov wrote:
Andrey Semashev wrote:
Hello,
I'd like to ask if it is possible to make Boost.Lambda place holders _1, _2 and _3 compatible with Boost.Bind?
The latest version of Bind supports arbitrary placeholders via the TR1-compatible is_placeholder<> trait/metafunction. See libs/bind/test/bind_placeholder_test.cpp for an example.
I was going to add that now we just have to specialize is_placeholder for Lambda's placeholders, but closer investigation on my part revealed that someone going by the nickname of 'pdimov' already did that 9 months ago:
http://boost.cvs.sourceforge.net/boost/boost/boost/lambda/detail/lambda_functors.hpp?r1=1.7&r2=1.8
:-)
Nice. :) But will it work with lambda? I.e. will this work: using namespace std; using namespace boost; for_each(v.begin(), v.end(), lambda::var(cout) << _1); Note the placeholder is not lambda::_1. -- Best regards, Andrey mailto:andysem@mail.ru
Andrey Semashev wrote:
But will it work with lambda? I.e. will this work:
using namespace std; using namespace boost;
for_each(v.begin(), v.end(), lambda::var(cout) << _1);
Note the placeholder is not lambda::_1.
No, this won't work, unfortunately. Lambda doesn't work with Bind's placeholders. I don't know how difficult it'd be to make it support is_placeholder.
Hello Peter, Monday, April 9, 2007, 10:22:56 PM, you wrote:
Andrey Semashev wrote:
But will it work with lambda? I.e. will this work:
using namespace std; using namespace boost;
for_each(v.begin(), v.end(), lambda::var(cout) << _1);
Note the placeholder is not lambda::_1.
No, this won't work, unfortunately. Lambda doesn't work with Bind's placeholders. I don't know how difficult it'd be to make it support is_placeholder.
Well, that's exactly what I wanted to have. As a user I see no need in different placeholders for lambda and bind. -- Best regards, Andrey mailto:andysem@mail.ru
On 4/9/07, Peter Dimov <pdimov@mmltd.net> wrote:
Andrey Semashev wrote:
But will it work with lambda? I.e. will this work:
using namespace std; using namespace boost;
for_each(v.begin(), v.end(), lambda::var(cout) << _1);
Note the placeholder is not lambda::_1.
No, this won't work, unfortunately. Lambda doesn't work with Bind's placeholders. I don't know how difficult it'd be to make it support is_placeholder.
I'm still working on adding TR1 result_of compatibility to lambda, and I think I'll try adding TR1 placeholder and bind compatibility at the same time. They're all defined in <funcitonal> and to make one work nicely you kind of need to look at the other two. At least, I keep finding myself looking at them. Hopefully, Peter's specializations of is_placeholder will help things along, and it won't be too difficult, though writing test cases for this stuff is time consuming. My intention is to add the TR1 functionality to the current lambda conventions without breaking existing user code. I think this could be useful as a transition to the upcoming merged lambda/Phoenix. It will give users a chance to start using TR1 with lambda without forcing them to. If users are informed that the pre-TR1 conventions are deprecated, then during the Phoenix merger you won't have to worry about backwards compatibility. Users will have already been warned and had a chance to upgrade their code to use TR1. With regard to result_of, I'm planning on changing the documentation to say that the sig member template is deprecated, and user's should employ the TR1-style result member template. When I submit these changes for the list's consideration would you prefer that lambda's placeholders and lambda::bind also be documented as deprecated in favor of their TR1 counterparts; i.e. looking to the future with the new standard, should lambda duplicate the new standard library's functionality? Daniel
participants (5)
-
Andrey Semashev -
Daniel Walker -
Eric Niebler -
Joel de Guzman -
Peter Dimov