[mpl] is_lambda_expression bug?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[mpl] is_lambda_expression bug?

James Hirschorn
The compile-time assertion fails in the following program. I have tried with
more than one version of boost including 1.53.

Is it a bug? Shall I report it?

--------------------------------------------------

#include <boost/mpl/assert.hpp>
#include <boost/mpl/lambda.hpp>
#include <boost/mpl/plus.hpp>

namespace mpl = boost::mpl;

struct MetafunctionClass
{
        template<typename T1, typename T2>
        struct apply
        {
                typedef typename mpl::plus<T1,T2>::type type;
        };
};

BOOST_MPL_ASSERT((mpl::is_lambda_expression<MetafunctionClass>));

int main(int argc, char * argv[])
{
}
--------------------------------------------------




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Jeffrey Lee Hellrung, Jr.-2
On Fri, Feb 8, 2013 at 9:04 AM, James Hirschorn <[hidden email]
> wrote:

> The compile-time assertion fails in the following program. I have tried
> with
> more than one version of boost including 1.53.
>
> Is it a bug? Shall I report it?
>
> --------------------------------------------------
>
> #include <boost/mpl/assert.hpp>
> #include <boost/mpl/lambda.hpp>
> #include <boost/mpl/plus.hpp>
>
> namespace mpl = boost::mpl;
>
> struct MetafunctionClass
> {
>         template<typename T1, typename T2>
>         struct apply
>         {
>                 typedef typename mpl::plus<T1,T2>::type type;
>         };
> };
>
> BOOST_MPL_ASSERT((mpl::is_lambda_expression<MetafunctionClass>));
>
> int main(int argc, char * argv[])
> {
> }
>

I can't find any documentation for is_lambda_expression...though I didn't
look very hard...is it part of the public API?

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

James Hirschorn
Jeffrey Lee Hellrung, Jr.-2 wrote
I can't find any documentation for is_lambda_expression...though I didn't
look very hard...is it part of the public API?
I do not believe it is in the documentation.
But since it's part of the public interface shouldn't it be required to work correctly?

Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Jeffrey Lee Hellrung, Jr.-2
On Fri, Feb 8, 2013 at 1:17 PM, James Hirschorn <[hidden email]
> wrote:

> Jeffrey Lee Hellrung, Jr.-2 wrote
> > I can't find any documentation for is_lambda_expression...though I didn't
> > look very hard...is it part of the public API?
>
> I do not believe it is in the documentation.
> But since it's part of the public interface shouldn't it be required to
> work
> correctly?
>

Can you point to something that indicates it is in fact part of the public
interface? If it's not documented, I don't know what properties
is_lambda_expression has and what guarantees it makes. Its name suggests
some, I admit, but who knows what the author's intents were? Without some
additional documentation, the code defines its behavior, hence I'd say it's
tautologically correct :)

I can sympathize if you think the above implies this metafunction should be
an auxiliary or detail namespace; I would agree.

Is this just an FYI, or are you genuinely in need to detecting Boost.MPL
lambda expressions?

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Nate Crookston
In reply to this post by James Hirschorn
Hi James,

James Hirschorn wrote:

> The compile-time assertion fails in the following program. I have tried
> with
> more than one version of boost including 1.53.
>
> Is it a bug? Shall I report it?
>
>
I agree with Jeff, that this isn't really part of the public interface -- I
can't find docs either.

The metafunction itself appears to detect placeholder expressions*: i.e.,
expressions involving arg<N> or mpl::bind<>, which it obviously wouldn't in
your code.  The following lines work:

BOOST_MPL_ASSERT_NOT((mpl::is_lambda_expression<MetafunctionClass>));
BOOST_MPL_ASSERT((mpl::is_lambda_expression<mpl::plus<mpl::_1,mpl::_2> >));

Though it would be unwise to depend on it.

HTH,
Nate


*
http://www.boost.org/doc/libs/1_53_0/libs/mpl/doc/refmanual/placeholder-expression.html

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

James Hirschorn
Nathan Crookston wrote
I agree with Jeff, that this isn't really part of the public interface -- I
can't find docs either.
It is part of the public interface (whether or not intentionally) because my client code can access it.
Being undocumented is another issue.

The metafunction itself appears to detect placeholder expressions*: i.e., ...
Then it should be called is_placeholder_expression


Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

James Hirschorn
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
Jeffrey Lee Hellrung, Jr.-2 wrote
If it's not documented, I don't know what properties is_lambda_expression has and what guarantees it makes. Its name suggests some, I admit, but who knows what the author's intents were? Without some additional documentation, the code defines its behavior, hence I'd say it's tautologically correct :) I can sympathize if you think the above implies this metafunction should be an auxiliary or detail namespace; I would agree.
I would think (but I don't really know) that having undocumented functions in the main namespaces would itself be a violation of boost policies, even if it worked as expected. On this basis I think I will make a report and see what they say.

Even if it was hidden, it seems like horrible style to have is_lambda_expression fail on lambda expressions (there is a documented is_sequence metafunction, and there is an is_placeholder in the mpl namespace that seems to work as expected).

Is this just an FYI, or are you genuinely in need to detecting Boost.MPL lambda expressions?
Yes, there is a need. I want a function to be instantiated according to its template parameters (e.g. one definition if T1 is a lambda_expression and another if T1 is a sequence (or is there overlap?)).
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Jeffrey Lee Hellrung, Jr.-2
On Sat, Feb 9, 2013 at 10:12 PM, James Hirschorn <
[hidden email]> wrote:

> Jeffrey Lee Hellrung, Jr.-2 wrote
> >  If it's not documented, I don't know what propertiesis_lambda_expression
> > has and what guarantees it makes. Its name suggestssome, I admit, but who
> > knows what the author's intents were? Without someadditional
> > documentation, the code defines its behavior, hence I'd say
> > it'stautologically correct :)I can sympathize if you think the above
> > implies this metafunction should bean auxiliary or detail namespace; I
> > would agree.
>
> I would think (but I don't really know) that having undocumented functions
> in the main namespaces would itself be a violation of boost policies, even
> if it worked as expected.


AFAIK, it's not a boost policy violation, though I agree it's generally not
good practice.

On this basis I think I will make a report and see
> what they say.
>

Can't argue with that.


> Even if it was hidden, it seems like horrible style to have
> is_lambda_expression fail on lambda expressions (there is a documented
> is_sequence metafunction, and there is an is_placeholder in the mpl
> namespace that seems to work as expected).
>

Yes, I agree that it's poorly named. At least based on your report and my
quick glance at the code.


> > Is this just an FYI, or are you genuinely in need to detecting
> > Boost.MPLlambda expressions?
>
> Yes, there is a need. I want a function to be instantiated according to its
> template parameters (e.g. one definition if T1 is a lambda_expression and
> another if T1 is a sequence (or is there overlap?)).
>

Well, one solution is to assume T1 is a lambda expression if it's not a
sequence. Another solution is to implement your own is_lambda_expression
metafunction. Or, who knows, maybe if you continue to troll through the MPL
headers, you'll find what you're looking for :)

Anyways, sorry you didn't get the answer you were probably hoping for.
C'est la vie.

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Edward Diener-3
In reply to this post by James Hirschorn
On 2/10/2013 1:12 AM, James Hirschorn wrote:

> Jeffrey Lee Hellrung, Jr.-2 wrote
>>   If it's not documented, I don't know what propertiesis_lambda_expression
>> has and what guarantees it makes. Its name suggestssome, I admit, but who
>> knows what the author's intents were? Without someadditional
>> documentation, the code defines its behavior, hence I'd say
>> it'stautologically correct :)I can sympathize if you think the above
>> implies this metafunction should bean auxiliary or detail namespace; I
>> would agree.
>
> I would think (but I don't really know) that having undocumented functions
> in the main namespaces would itself be a violation of boost policies, even
> if it worked as expected. On this basis I think I will make a report and see
> what they say.
> Even if it was hidden, it seems like horrible style to have
> is_lambda_expression fail on lambda expressions (there is a documented
> is_sequence metafunction, and there is an is_placeholder in the mpl
> namespace that seems to work as expected).
>
>> Is this just an FYI, or are you genuinely in need to detecting
>> Boost.MPLlambda expressions?
>
> Yes, there is a need. I want a function to be instantiated according to its
> template parameters (e.g. one definition if T1 is a lambda_expression and
> another if T1 is a sequence (or is there overlap?)).

In the latest version of tti on the trunk, I have an
is_lambda_expression metafunction as a detail of the implementation. You
can find it at tti/detail/dlambda.hpp. I use it at one point in the
implementation when introspecting a nested type and allowing the user to
optionally apply a lambda expression when found, a suggestion made by
Jeffrey Hellrung when tti was reviewed.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

James Hirschorn
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
Jeffrey Lee Hellrung, Jr.-2 wrote
On this basis I think I will make a report and see
> what they say.
>

Can't argue with that.
I'm now convinced it is a bug, because mpl::transform uses mpl::is_lambda_expression for the exact same purpose as my application, and it clearly assumes that is_lambda_expression behaves according to its name. I will make an example to submit with the report.

Well, one solution is to assume T1 is a lambda expression if it's not a
sequence. ...
This is currently how e.g. mpl::transform behaves, but it's incorrect because a class can be both a sequence and a lambda expression in which case it is supposed to be treated as an operator.
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

James Hirschorn
In reply to this post by Edward Diener-3
Edward Diener-3 wrote
In the latest version of tti on the trunk, I have an
is_lambda_expression metafunction as a detail of the implementation. You
can find it at tti/detail/dlambda.hpp. I use it at one point in the
implementation when introspecting a nested type and allowing the user to
optionally apply a lambda expression when found, a suggestion made by
Jeffrey Hellrung when tti was reviewed.
I verified that it works correctly with the example I gave. I will use this for now, and perhaps it should be shared with mpl ...
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Jeffrey Lee Hellrung, Jr.-2
On Mon, Feb 11, 2013 at 10:44 PM, James Hirschorn <
[hidden email]> wrote:

> Edward Diener-3 wrote
> > In the latest version of tti on the trunk, I have an
> > is_lambda_expression metafunction as a detail of the implementation. You
> > can find it at tti/detail/dlambda.hpp. I use it at one point in the
> > implementation when introspecting a nested type and allowing the user to
> > optionally apply a lambda expression when found, a suggestion made by
> > Jeffrey Hellrung when tti was reviewed.
>
> I verified that it works correctly with the example I gave. I will use this
> for now, and perhaps it should be shared with mpl ...
>

+1

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [mpl] is_lambda_expression bug?

Edward Diener-3
In reply to this post by James Hirschorn
On 02/12/2013 01:44 AM, James Hirschorn wrote:

> Edward Diener-3 wrote
>> In the latest version of tti on the trunk, I have an
>> is_lambda_expression metafunction as a detail of the implementation. You
>> can find it at tti/detail/dlambda.hpp. I use it at one point in the
>> implementation when introspecting a nested type and allowing the user to
>> optionally apply a lambda expression when found, a suggestion made by
>> Jeffrey Hellrung when tti was reviewed.
>
> I verified that it works correctly with the example I gave. I will use this
> for now, and perhaps it should be shared with mpl ...

tti depends on mpl so it probably belongs in mpl.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost