Re: [boost] [parameter] Lazy binding and operator|| patch

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-03-22 16:35:08

On 3/22/07, David Abrahams <dave_at_[hidden]> wrote:
>
> on Thu Mar 22 2007, Daniel Wallin <daniel-AT-boost-consulting.com> wrote:
>
> > David Abrahams wrote:
> >> on Tue Mar 20 2007, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
> >>> These patches do not need to be applied in any particular order.
> >>> Applying all three has the effect of making lazy binding behave more
> >>> like the description in the documentation. I ran the Boost Parameter
> >>> Library test suite and everything passed. Let me know if I've
> >>> misunderstood something or if there's a better way to solve this
> >>> problem or if you'd like additional documentation/tests.
> >>
> >> I don't have any suggestions, though maybe Daniel W. does.
> >
> > I think in general a better solution would be to add a member function
> > to the keyword class template. Maybe:
> >
> >   template <class F>
> >   ... lazy(F const& f)
> >   {}
>
> As a substitute for op|| ?
>
> I would rather call it lazy_default.
>
> However, I think the solution is in the lambda library already:
> http://boost.org/doc/html/lambda/le_in_details.html#lambda.unlambda

Really, users just need to provide a result_of compatible function
object. So if the documentation says that more clearly and replaces
the lambda example with a bind example, it would alleviate confusion.

Unlambda gets rid of the operator|| overload resolution problem, but
doesn't generate a lambda compatible functor as far as I know... at
least not yet.

For 1.34, since users can't use lambda anyway (due to lack of
result_of compatibility) there's no need for this patch or renaming
op||. In the future, if/when lambda is result_of compatible,
keyword::operator|| will need to be renamed or somthing like this
patch should be applied. My preference is to keep the current syntax.
I kind of like using args[ _arg || default() ] better than args[
_arg.lazy(default()) ], especially if there's still args[ _arg |
default() ].

>
> > And possibly change the docs to not use Boost.Lambda. We're going to
> > hit the same problem with the every lambda library. Changing the
> > implementation is to late for 1.34, but we should probably change
> > the docs so they don't mention Lambda. The example would become:
> >
> >   bind(std::plus<std::string>(), ref(s1), ref(s2))
> >
> > it's unfortunate, but not that bad IMO.
>
> Is it better not to discuss lambda, or to mention unlambda as a way
> around this problem?

For 1.34, yes, I think it's better not to mention it.

Daniel