Re: [boost] Re: Review Request: FC++

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-10 13:24:42

--On Friday, October 10, 2003 12:32 PM -0400 David Abrahams 
<dave_at_[hidden]> wrote:

> Mat Marcus <mat-boost_at_[hidden]> writes:
>
>>> I think it's silly to externalize everything, and (meta)functions
>>> are the kind of tiny single-purpose objects which can be allowed
>>> to have constraints.  Otherwise, why constrain your meta_apply
>>> either?  And then, how do you invoke it?
>>
>> Same question as above. If I believe that the ::type/::value idiom
>> is sufficiently entrenched then I might argue that requiring the
>> nested type is appropriate. However if I wanted to allow a broader
>> set of models that might happen to us other names (RET, result_of,
>> sig?) then maybe I would prefer that the concept was defined in
>> terms of
>
> What is:
>
>> a pay as you go specializable free metafunction with a well-defined
>> calling convention.
>

I probably should have left this sentence out since it doesn't really
add much to my point. But here's what I meant. I want my model to be
able to satisfy the metafunction class concept with no intrusion via
specialization of a free metafunction instead of requiring a nested
apply. Pay as you go means I could do so in a sepearate header so that
clients unconcerned with MPL don't have to include it. A well defined
calling convention means that its fine to impose constraints on this
external creature since it is non-intrusive.

>> This is essentially the same as the call() question above but at
>> compile time. I think that a nested apply is not used as widely.
>
> It's true that there are two metafunction concepts:
>
> Metafunction: a class template taking only type parameters and having
> a nested ::type type.
>
> Metafunction Class: a class having a publicly-accessible nested
> Metafunction called "apply".
>
> And it's also true that Metafunction is the more-fundamental of the
> two.
>
> So you could redefine Metafunction Class in terms of the "mpl::apply"
> Metafunction.

Yes this is what I want.

> However, you can't redefine Metafunction in terms of
> any other Metafunction or you have infinite recursion.  That's my
> point.
>
> Also, although Metafunction is more fundamental, it requires more
> infrastructure (lambda) to do higher-order functional programming
> with it.  A metafunction class can be passed to a metafunction
> directly.  I believe there *may* be good efficiency reason to
> preserve its current definition.

Sure, I'm familiar with the use of metafunction classes. Let me just
make sure that I understand the tradeoff you are describing here. I
might like to relax the requirements on models of metafunction class
in order to admit a wider set of representatives. But there is no
known way to avoid the compile time inefficiencies incurred by the
external apply over the nested apply. Is that the point? In the
runtime world we have inlining and as a result I'm used to waving my
hands and saying that the generic style doesn't incur extra overhead
on a "reasonable compiler". I suppose there's not really an analog in
the compile time world. If the only requirement on metafunction
classes was the invokability of the free apply, MPL could perhaps look
first to see if a nested version existed, but even the looking takes
time.

 - Mat