|
Boost : |
Subject: Re: [boost] painless currying
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-08-24 12:52:41
On Wed, Aug 24, 2011 at 5:13 PM, Eric Niebler <eric_at_[hidden]> wrote:
> On 8/24/2011 1:58 AM, Roman Perepelitsa wrote:
>> 2011/8/23 Eric Niebler <eric_at_[hidden]>
<snip>
>> By the way, don't you need to manually pass arity in the general case? What
>> if the underlying functor is callable with one argument, but also with two?
>
> As soon as enough arguments are collected to make a valid call of the
> curried function, it gets called. This seems reasonable to me.
>
>> I think this is the case with functors generated by bind -- they appear to
>> be callable with any number of arguments.
>
> Ouch. :-(
Exactly. They need to be called with N number of arguments where N is
larger than highest arity of the placeholders used (_1 has arity 1, _2
has 2 and so on ...).
This is needed to allow to omit some of the passed parameters. For
example asio callbacks were you might not be interested in the number
of bytes written.
> One option, which I don't like, is to "fix" bind to disable any
> operator() overloads that result in an invalid invocation of the bound
> function. That can be done easily with the is_callable_with metafunction
> in my curryable implementation, but would reduce portability somewhat.
We can certainly disable certain operator() overloads for phoenix
actors. this is on my TODO for a very long time now ... Its actually
quite simple. just introspect the current expression and look for
placeholders.
Reusing your is_callable_with metafunction would be cool to disable
the bind functions for functors.
>> FWIW, Egg<http://p-stade.sourceforge.net/egg/doc/html/egg/function_adaptors.html>has
>> curryN (where N is a number literal) and uncurry.
>
> Of course, I'd prefer it if it just worked without needing to be told
> the arity. That's what I was aiming for.
I would like to pursue a general curry approach which just calls the
function whenever it could be called, and the curryN approache to tell
exactly which overload i woul dlike to have.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk