Re: [boost] [mpl] Metafunction terminology - revival?
----- Mensaje original ----- De: David Bergman <David.Bergman@bergmangupta.com> Fecha: Lunes, Julio 24, 2006 7:33 pm Asunto: [boost] [mpl] Metafunction terminology - revival?
Ok, I don't know what happened to the old discussion about naming of stuff that can be safely applied by mpl::apply.
We have the following constructs:
1. "metafunctions," which are templates classes with a type identifier called 'type',
2. "metafunction classes," which are classes with a nested template class called 'apply', which is a "metafunction" in its own right, and
3. "lambda expression."
Two of them - #2 and #3 - share a quite important trait: they can be passed as the first argument to mpl::apply.
I suggest that we call anything applicable via mpl::apply a "metafunctor."And have "metafunctoid" denote that category extended with #1 - ordinary metafunctions - above.
It is a bit boring not to be able to use a common name for these constructs,especially when trying to tech others about metaprogramming techniques in C++. And I do not see such common names in the MPL documentation (or book.)
Hello David, Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression: http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something? (I've got the hunch I am, actually.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin wrote (y escribio):
Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression:
http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html
actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something? (I've got the hunch I am, actually.)
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. 2. (Yours) All metafunction classes are "lambda expressions." 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. 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 :-) /David
"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. 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.boost-consulting.com
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
Joaquín López Muñoz writes:
Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression:
http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html
actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something?
Nope, you are 100% correct. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Joaquín López Muñoz writes:
Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression:
http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html
actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something?
Nope, you are 100% correct.
Ok, so struct Map { template<typename T> struct apply { typedef int type; }; }; is a "lambda expression" then? A bit weird in my book, but if that is the official nomenclature for MPL, I will use it... By the way, Aleksey, what do you think of calling anything applicable via mpl::apply a "metafunctor"? /David
"David Bergman" <David.Bergman@bergmangupta.com> writes:
Aleksey Gurtovoy wrote:
Joaquín López Muñoz writes:
Please correct if I'm wrong, but I'd say the official
definition for a
MPL lambda expression:
http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html
actually encompasses both metafunction classes and placeholder
expressions ("proper" lambda expressions, if you wish), so "lambda
expression" is the common name you're after. Am I missing something?
Nope, you are 100% correct.
Ok, so
struct Map { template<typename T> struct apply { typedef int type;
}; };
is a "lambda expression" then?
No but, Map is a lambda expression.
A bit weird in my book, but if that is the
official nomenclature for MPL, I will use it...
By the way, Aleksey, what do you think of calling anything applicable via
mpl::apply a "metafunctor"?
That's exactly a "lambda expression;" there's no need for a new term. The documentation for apply which says "Invokes a Metafunction Class or a Lambda Expression F with arguments A1,... An." is just redundant and should probably be fixed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I wrote:
Ok, so
struct Map { template<typename T> struct apply { typedef int type;
}; };
is a "lambda expression" then?
David Abrahams wrote:
No but,
Map
is a lambda expression.
Did you honestly think that I was refering to the *definition* per se, and not the *defined entity* (Map)? ... The reason that "metafunctor" is not that intimidating to more junior (w.r.t. meta programming) is that they have learned the use of "functors" in generic algorithms and such in C++. And it seems to me that things being applicable via mpl::apply is the closest we get to that notion. /David
David Bergman writes:
Aleksey Gurtovoy wrote:
Joaquín López Muñoz writes:
Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression:
http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html
actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something?
Nope, you are 100% correct.
Ok, so
struct Map { template<typename T> struct apply { typedef int type; }; };
is a "lambda expression" then?
One of its forms, and among other things, yes.
A bit weird in my book, but if that is the official nomenclature for MPL, I will use it...
By the way, Aleksey, what do you think of calling anything applicable via mpl::apply a "metafunctor"?
Being one of these people who frown upon the term "functor" (http://groups.google.com/group/boost-list/msg/d3d7546f3e8b1188), I'm not in favor of this one, for obvious reasons :). -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey wrote:
By the way, Aleksey, what do you think of calling anything applicable via mpl::apply a "metafunctor"?
Being one of these people who frown upon the term "functor" (http://groups.google.com/group/boost-list/msg/d3d7546f3e8b118 8), I'm not in favor of this one, for obvious reasons :).
Between you and me, I am not a fan of that "functor" use either, and would love for it to stay in category theory or at least be exclusive for notions mirroring that semantics, BUT: that is what those non-meta people say :-) ... or "function object," which would translate most conveniently to "meta function class"... /Now a reformed lambda expressionist :-)
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
Hello David,
Please correct if I'm wrong, but I'd say the official definition for a MPL lambda expression:
http://boost.org/libs/mpl/doc/refmanual/lambda-expression.html
actually encompasses both metafunction classes and placeholder expressions ("proper" lambda expressions, if you wish), so "lambda expression" is the common name you're after. Am I missing something? (I've got the hunch I am, actually.)
No, you're right. I just forgot; sorry for the confusion everyone. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
Aleksey Gurtovoy -
David Abrahams -
David Bergman -
JOAQUIN LOPEZ MU?Z