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
> I try to explain myself better with an example starting from the
> normal functions case:
> So here we have:
> msf::function<mpl::vector<_1(_1, _1), bool(_1)> >
> 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
>> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk