Re: [Implementation] Calling wrapped functions, converters, policies

Daniel Wallin <[email protected]> writes:

> David Abrahams wrote:
>
>> Daniel Wallin <[email protected]> writes:
>
>>>Still, I don't think it's sufficient for the case when you want one
>>>converter to operate on several arguments.
>> In other words, when one C++ argument comes from several Python/Lua
>> args?  Why not?
>
> Hm, I might have misunderstood. My interpretation was that we would
> somehow produce one argument_package for each CallPolicy in the
> sequence, starting from the native package. Looking back, that's how I
> interpret it now as well..
>
> Are you not implying that we wouldn't have any chaining at all? Or at
> least only one step of chaining?

Yes, one incoming argument package for each CallPolicy in the
sequence.  But let me be clear, although those CallPolicies in the
sequence are conceptually all siblings in my proposed arrangement, it
is possible to generate a parent-child relationship as well, by
wrapping that sequence in another CallPolicy which preprocesses the
argument_package.

> I've been thinking about this some more. Maybe argument_package just
> isn't enough. I think we need a way for the converter to filter the
> argument's passed to all trailing converters. Consider a converter
> which operates on 2 lua/python arguments and produces one C++
> argument. We
> could have something like:
>
>    void f(int a, int b);
>    def(&f, add_policy(_1, _2));
>
>    :: f(1, 2, 3) -> f(3, 3)
>
> The invoke-code would look something like:
>
>    f(
>        converters.convert(args, mpl::int_<0>())
>      , converters.convert(args, mpl::int_<1>())
>    );
>
> But when the second converter asks the argument_package for index 1 it
> should get index 2 because the first converter skips one index. This
> won't work with the simple argument_package idea since the operation is
> dependent on the order in which the package is composed. Also the first
> converter will ask the package for index 1 as well, and expects to get
> the unfiltered index..
>
> argument_package's can only handle operations which are commutative with
> respect to composition order. For instance, offset every argument N
> steps or switch positions for some arguments.
>
> So what I'm saying is that we might need two different concepts here.
> ArgumentPackage, which is global for all index operations. And
> IndexFilter (or something with a better name) which is connected to a
> single converter, and is applied to all trailing converters.
>
> We would end up with something similar to:
>
>    native_pkg args;
>
>    f(
>        cv0(args, 0)
>      , cv1(cv0.index_filter(args), 1)
>      , cv2(cv0.index_filter(cv1.index_filter(args)), 2)
>    );
>
> I find this hard to explain well. Does it make any sense?

I think I understand it, but I think it's too difficult.  IMO we need
to come up with something that's conceptually easier to manage.

Let's take a step back and look at the DSL for specifying policies.
First of all, we need to decide whether "_1" refers to C++ arguments
or Python/Lua arguments, or both.

I would be strongly inclined to say that unless you _explicitly_ say
otherwise, each C++ argument comes from the Py/Lu argument in the
same position.  Your example uses implicit argument shifting, which
makes me  nervous.  Suppose you wrote:

      _1 <- _1+_2,  _2 <- _3

instead??

If you want to say, "shift the rest of the arguments the same way",
you might write:

      _1 <- _1+_2,  _2 <- _3, etc
    
;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/