[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.) /David
"David Bergman" <David.Bergman@bergmangupta.com> writes:
I suggest that we call anything applicable via mpl::apply a "metafunctor." And have "metafunctoid" denote that category extended with #1 - ordinary metafunctions - above.
No strong objection
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.)
Yeah, we managed to write the whole book without such a name, which suggests maybe it isn't really needed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I whined:
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 C++book.)
David Abrahams responded:
Yeah, we managed to write the whole book without such a name, which suggests maybe it isn't really needed.
That is true for experienced folks, but seems to break down when teaching this subject to more junior colleagues. So, I will use "metafunctor" and "metafunctoid" till further notice (in the form of a revision of the MPL documentation) ;-) "Yes, just create a metafunctor, whichever way you like - lambda, explicitly... - and use it!" /David
David Bergman wrote:
So, I will use "metafunctor" and "metafunctoid" till further notice (in the form of a revision of the MPL documentation) ;-)
While your in there changing MPL docs, could you do us the favor of adding some of the missing copyright+license information. MPL is *1* in the number of those issues. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Mon, 24 Jul 2006 13:06:03 -0500, Rene Rivera <grafikrobot@gmail.com> wrote:
While your in there changing MPL docs, could you do us the favor of adding some of the missing copyright+license information. MPL is *1* in the number of those issues.
Rene, next time we should remember to run the inspect tool (and fix its discoveries :-)) before branching for release, so that we don't have to duplicate all corrections on head and branch. Or maybe the inspect tool should run once a week or so, in general. PS: maybe we want to highlight this in a separate thread? -- [ Gennaro Prota, C++ developer for hire ]
"David Bergman" <David.Bergman@bergmangupta.com> writes:
I whined:
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 C++book.)
David Abrahams responded:
Yeah, we managed to write the whole book without such a name, which suggests maybe it isn't really needed.
That is true for experienced folks, but seems to break down when teaching this subject to more junior colleagues.
Our book is not directed at "more experienced folks"
So, I will use "metafunctor" and "metafunctoid"
Those terms don't intimidate junior colleagues? They intimidate me! -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Tue, 25 Jul 2006 10:44:14 -0400, David Abrahams <dave@boost-consulting.com> wrote:
So, I will use "metafunctor" and "metafunctoid"
Those terms don't intimidate junior colleagues? They intimidate me!
Nah, don't let them do. They are just thin wrappers around Greek terminology ;-) -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Tue, 25 Jul 2006 10:44:14 -0400, David Abrahams <dave@boost-consulting.com> wrote:
So, I will use "metafunctor" and "metafunctoid"
Those terms don't intimidate junior colleagues? They intimidate me!
Nah, don't let them do. They are just thin wrappers around Greek terminology ;-)
Do "...or" and "...oid" really connote distinct meanings? That's the problem I have with them. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 08:11 AM 7/28/2006, Dave Abrahams wrote:
On Tue, 25 Jul 2006 10:44:14 -0400, David Abrahams <dave@boost-consulting.com> wrote:
So, I will use "metafunctor" and "metafunctoid"
Those terms don't intimidate junior colleagues? They intimidate me!
Nah, don't let them do. They are just thin wrappers around Greek terminology ;-)
Do "...or" and "...oid" really connote distinct meanings? That's the problem I have with them
As near as I can tell, the terms are being applied pretty arbitrarilly -- they have almost no useful a-priori connotation at all. According to Miriam-Webster on-line: the ending "-or" means "one who does a (specified) thing" so, for example, a "grantor" is one who "grants". An alternative meaning is "condition" or "activity". From the same source the ending "-oid" means either "something resembling a (specified) object" or "having a (specified) quality". Metafunctoid does fit this somewhat but its implicit meaning is pretty broad to be introduced to draw fine distinctions. As for "functor" it comes from Category Theory and is something that maps one category (broad mathematical structure, like the general idea of a "group") to another while preserving certain properties. With or without the "meta-" it doesn't seem at all relevant. It probably entered this area of discussion by way of Prolog which used the term to designate the atom that started a structure. The probable intention of this terminology, though, was "function" meaning "purpose" -- the "functor" was the thing that specified the purpose, or meaning, of the structure. So in (father-of jim tom) the functor is father-of. To be useful (interpretable) use of a particular functor implies that the structure has a particular "arity" with each position having an implied meaning and therefore implicit type (essentially -- an expectation that only certain atoms or structures with certain functors will appear at that position). A "functor" in Prolog pretty much corresponds to "class" in C++. Since Prolog, "functors" as things that tag a list implying the number and types of the elements has entered a number of languages/data systems (e.g., Eclipse). Structures representing "function invocations" are certainly applicable and the pressure of a false etymology certainly encourages that specific narrowed usage. But it is a false etymology and, I would say, is best avoided. Topher
participants (5)
-
David Abrahams -
David Bergman -
Gennaro Prota -
Rene Rivera -
Topher Cooper