Re: [boost] [mpl] Metafunction terminology - revival?

From: David Bergman (David.Bergman_at_[hidden])
Date: 2006-07-25 13:42:53

David Abrahams wrote: 

> "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.

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