
Boost : 
From: David Abrahams (dave_at_[hidden])
Date: 20060725 10:58:04
"David Bergman" <David.Bergman_at_[hidden]> writes:
> Ok, two interpretations:
>
> 1. (Mine) What the MPL documentation calls a "lambda expression" (as of the
> refered page) is either "placeholder expression" or meta function classes
> *generated* by the application of mpl::lambda, i.e., *just* the meta
> function classes generated in that specific way.
It would be perverse, IMO, to call some types lambda expressions only
by virtue of how the type was generated. If I write down a type that
is exactly identical to mpl::lambda<mpl::identity<_> >::type, but I
don't use mpl::lambda to write that type, by your definition it is not
a lambda expression. In other words, by your definition:
mpl::lambda<mpl::identity<_> >::type
is a lambda expression, and yet
is_same<mpl::lambda<mpl::identity<_> >::type, x>::value
does not imply that x is a lambda expression.
> 2. (Yours) All metafunction classes are "lambda expressions."
2. is correct.
> I am admittedly biased, but I think my interpretation is the most sound one
> ;)
> The reason for that is that I would hesitate to call an explicitly
> defined metafunction class, such as
>
> struct MyMeta { template<class T> apply { typedef int type; } };
>
> a lambda expression.
That's a circular reason. You think your interpretation of the
meaning of the term is the most sound because you would hesitate to
apply the term to such a class.
MyMeta
is a lambda expression. Consider:
template <class T> struct always_int { typedef int type; };
typedef always_int<_1> MyMeta;
now
MyMeta
is again a lambda expression.
> I still want to tell my "students" that they should implement a
> "metafunctor" rather than a "lambda expression," which I consider to
> be a proper sub set of the former :)
You are of course free to pick your own terminology, but that's not
the "official MPL" terminology and IMO you will just confuse your
students, which would be a disservice.
 Dave Abrahams Boost Consulting www.boostconsulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk