Re: [boost] [announce] Multi signature boost::function v1.0

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-05-19 10:26:57

On Sat, May 17, 2008 at 1:39 AM, Marco Costalba <mcostalba_at_[hidden]> wrote:
> On Fri, May 16, 2008 at 9:03 PM, Daniel Walker
> <daniel.j.walker_at_[hidden]> wrote:
>>
>> It's still a vector of signatures. There are two kinds of signature
>> here (by convention or protocol):
>>
>> * int(int, int) is the usual C/C++ call signature
>> * plus(_1,_1) is our new emerging polymorphic signature by convention
>>
>
> Ok, now I understand, thanks, but still there is a fundamental
> difference between int(int, int) and plus(_1,_1), namely the first
> it's just an interface but the latter does real work, actually adds
> stuff.
>
> I try to explain myself better with an example starting from the
> normal functions case:
>
<snip>
>
> So here we have:
>
> msf::function<mpl::vector<_1(_1, _1), bool(_1)> >
>
> not
>
> msf::function<mpl::vector<plus(_1, _1), is_positive(_1)> >
>
> because the vector of function signatures define the interface that
> function should have to be wrapped by the overload set, as you prefer
> to call it ;-), so also in polymorphic case the vector should keep
> "polymorphic signatures" that different polymorphic classes with the
> proper polymorphic signature should match to be _wrapped_ by the
> overload set, not to be the underlying function, replacing
> boost::function as you suggested.
>
> In this case boost::function should be replaced by a wrapper of
> polymorphic functors, not by _a_ polymorphic functor defined in
> mpl::vector at msf::function instantiation.
>
> Am I missing something?
>
> BTW I don't even figure up how this wrapper of poly objects looks like
> ! or if it even exist.

This is interesting, but something different. _1(_1,_1) and bool(_1)
are not what I meant by polymorphic signature. I haven't thought about
how you would do this either or if it's even possible. The definition
for a polymorphic signature protocol that I have in mind requires that
the first position be a callable object or referenced wrapped callable
object. _1 and bool are not callable objects - no operator(). So, for
the first position, a polymorphic signature is almost exactly like the
signatures passed to result_of. (BTW, this could be enforced by the
compiler with a concept check.) For all the following positions in the
signature inside parens, they can be either an actual argument type or
a placeholder. Placeholders indicate a template parameter in the
function's argument list (not an unspecified function object outside
the argument list). Actually, come to think of it, _1(_1, _1) would
probably not be possible because it doesn't encode the type of a
polymorphic function object, so there's no way for the compiler to use
that type's set of overloaded operator()s later on at the call site.
_1(_1,_1) is type erasure again and that breaks polymorphic function
objects.

>>
>> I'm sure there's more to it, but that gives you an idea. Of course,
>> the first thing you need is an nary version of polymorphic_function.
>> If you're serious about this and that's the direction you'd like to go
>> in, I'd be glad to start working on it tomorrow!
>>
>
> Great!! I'm very interested in polymorphic generalization too, but I
> would think is difficult stuff, too difficult for me alone ;-)

Well, I ended up taking the weekend off. ;-) But I'll download your
latest version and get back with you later this week. This will be fun
if nothing else!

Daniel Walker