David Abrahams wrote:
"David Bergman" <David.Bergman@bergmangupta.com> 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.
Ok, then I am a perverse. I slight misunderstanding, though: I meant the "mpl::lambda<T>" by the "application of" and not "mpl::lambda<T>::type", sorry about that. I could definitely visualize a world where (only) the following two forms are called "lambda expressions": 1. The syntactic form - called "plaholder expression" in MPL 2. The lifting of that form to an applicable form; more concretely, mpl::lambda<PE>, where PE is such a syntactic form - this is a ready-to-be-applied (i.e., add "::type") form. That the latter form *evaluates* to a type equivalent to something we explicitly type, would not change that perverse world. I now know that MPL is not part of that wicked world of mine, but that everything that can be put as the first argument to "mpl::apply" is called a "lambda expression" no matter whether placeholder expressions were used or the identifier "mpl::lambda" was mentioned anywhere. Is that understanding correct? [snip]
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.
No, it is not. There is an inbound arrow to why I would hesitate to apply the term "lambda expresison" to my simple metafunction class, and that inbound arrow is that lambda expressions usually constitute a sub set of the definable forms in a real programming language, much like Boost.Lambda deals with lambda expressions. And from that derived hesitation there is the last arrow to why I think my interpretation is sound. What is more important, though, is that I now know that not only was my interpretation unsound, but invalid: in MPL, all applicable (via "mpl::apply") things are called "lambda expressions." [snip]
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.
They are confused by not having a notion similar to, even lexically similar to, those functors they pass around in generic algorithms for runtime execution. Such as a metafunctor... Now they will have to have lambda expressions, quite distinct from the more limited scope of lambda expressions they have seen in generic programming (Boost.Lambda, Boost.Spirit...) It is alright, I will just explain that "lambda expressions" in MPL are analogous to functors in generic (runtime) programming. And that "placeholder expression" are analogous to what they usually call lambda expressions. And that the form "mpl::lambda<PE>" does not warrant any special naming in itself. Thanks for clarifying my perverse issues. I am only being semi-sarcastic, actually. /David