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

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-10 11:00:14

[snip]
Mat:
>> It seems that today various libs, MPL included, may place too many
>> constraints on their collaborators. Instead of assuming that a
>> quoted metafunction, er excuse me, metafunction class ;-) has a
>> nested apply<> why not use a level of indirection and have it adhere
>> to a metaconcept instead. E.g. maybe its enough to require the
>> concept that meta_apply<meta_function_class>::type

Dave A:
>    mpl::apply<meta_function_class, T1, T2,... TN>::type

Ok, so mpl::apply exists. What I'm asking is what if MPL collaborators
were only required to assure that this external mpl::apply was
invokable with the right semantics, but didn't assume anything about
the internal structure of meta_function_class.

>> is utterable and has the correct semantics. Then libs wouldn't have
>> to be rewritten to internally follow designated naming
>> conventions. Instead they could model the required concepts (or is
>> that: metamodel the required metaconcepts) generically by providing
>> certain free metafunctions.

> You can carry this too far.  Can you imagine a functional programming
> library which didn't require nested operator(), and instead used an
> external call() free function?

I don't want to carry it too far. The goodness-criteria that I am
trying to apply in these thought experiments is to allow the broadest
possible set of representatives to be models of the libraries
concepts. This leads to a desire to avoid intrusive requirements such
has "a model of this concept shall have a nested X" where X may be a
type or member of some kind. I'm not sure how useful it would be to
employ an external call() free function since callability through
operator() is a pretty entrenched idiom.

>
> 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 a pay as
you go specializable free metafunction with a well-defined calling
convention. 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.

> We only got here because of the multi-purpose roles of apply/sig and
> operator() in full functoids ;-)
>
>> You could even have headers such as
>> functoid_as_meta_function_class.hpp following boost::graph's
>> vector_as_graph.hpp (except avoiding traits) example so that the
>> functionality could be added in layers, paying as you go. I am
>> tempted to apply these heuristics to boost:: and std:: and see how
>> various generic rewrites might look. The s/OO/generic/g rule would
>> be something like, "whenever a nested type (or traits, which
>> technically also use nested types) or a nested member (e.g. member
>> function or member variable) is used, add a level of indirection so
>> that collaborators have a chance to supply this function
>> externally".
>>
>> somebody-stop-me-soon-please-ly,
>
> Screech!

skidding-but-still-moving-ly,
Mat