[boost] Continuations (was: tandard interface for adaptable function objects?)

From: Miroslav Silovic (miro_at_[hidden])
Date: 2002-11-22 06:01:44

Anthony Williams wrote:

>Given that a functor might support more than one argument set, the only way I
>can think of is to say "do you support this argument set?" rather than "what
>argument set do you accept?"; in which case you can use the mechanism
>implemented in boost.lambda, and in my function composition library, to deduce
>the return type --- have a member template that takes a typelist representing the
>arguments you wish to pass, and returns the corresponding return type where
>that argument set is valid, or something else (such as invalid_argument_set)
>where it isn't (assuming you want to do something else in the case where it
>isn't, rather than just abort compilation)
>
>Does this give you what you want?
>  
>
Actually I was digging through lambda for something like this just 
yesterday (and found nothing). Shouldn't goodies like this be separated 
(and documented) into their own library? (the other thing I'd *really* 
like to see separated from lambda is operator argument promoting... the 
name of the header escapes me).

Incidentally, since I've already spent too much time on something that 
is basically a cool side-project.. has anybody implemented lightweight 
continuations in C++? I'm trying to convert functions of the form void 
foo(functor) into objects that can be operated on (kinda like lambda 
placeholders), and the results of the operation can then take functor - 
then lazilly evaluate all the calls (possibly with backtracking) and 
pass all the answers to the functor. Basically, the conversion itself 
then behaves like call/cc, while the compilation is somewhat like 
DS->CPS conversion. Except that unlike Scheme's continuations, these 
would just be shorthand for passing lambdas (and would be able to return 
after invocation).

The idea is that if a function cont_iterate calls a sink function over 
all the elements of a vector (can't use for_each here, because of the 
template issues), cond_apply calls a function on a bunch of 
continuations, and the_sink is a function that takes pairs of vector 
elements, you could do something like

cont_apply(pair, bind(cont_iterate, a_vector, _1), bind(cont_iterate, 
another_vector, _1))  (sink)

and the sink will be called with all the pairs of elements (but this 
will be done in a natural way, through backtracking). The code would 
expand into something like:

int r2;

void temporary1(int r)
{
    sink(pair(r2, r));
}

void temporary2(int r)
{
    r2 = r;
    cont_iterate(another_vector, temporary1);
}

void invocation()
{
    cont_iterate(a_vector, temporary2);
}

Fun thing about the continuations is that with these, you can implement 
microthreads VERY efficiently, as well as priority evaluation, and 
similar tricks. Basically most things you can do with Scheme's 
continuations - the only difference is that backtracking only happens 
up-the-stack.

The issue is that continuation objects need to maintain some state - at 
least the temporary results - and I need to query the functors for the 
result type. This is a problem.

Note also that the implementation of continuations should probably be 
something like lambda in reverse. The problem is that I'm not 
experienced enough with metaprogramming, so I could use any comments and 
advice that people here might have. Especially the pointers to the code 
I might want to reuse or look into.

    Miro