continuation barriers

continuation barriers

[Linas Vepstas]

I just tried continuations for the first time in my environment, and
promptly hit a continuation barrier.  I think I understand why,
-- its how I'm mixing C and guile -- but don't see any solution.

I think what I want is a "continuation since the last time I
entered guile, and don't worry about C because there
aint none" .

i.e. I'd like something like this to work:

scm_c_eval_string(" ... (call/cc (lambda (k) (set! *myk* k))) ...");
... some_c_code(...);
scm_c_eval_string(" ... (*myk* 42) ...");

I think (I haven't yet tried) that the above can work if I wrap
the whole darn thing with scm_with_guile() .. but is there
some way of getting the above to run without a big wrap
of this kind?

--linas

Re: continuation barriers

[Neil Jerram]

Linas Vepstas <linasvepstas@gmail.com> writes:

> i.e. I'd like something like this to work:
>
> scm_c_eval_string(" ... (call/cc (lambda (k) (set! *myk* k))) ...");
> ... some_c_code(...);
> scm_c_eval_string(" ... (*myk* 42) ...");

I think there are a couple of problems here.

The first is as you've noted, that scm_c_eval_string() has a
scm_c_with_continuation_barrier() hiding inside it.  You can avoid
that by using some other method for calling from C into Scheme, for
example:

(define (entry-point code)
  ... set up whatever catches you want around the 
      code that is going to be evaluated, e.g. for
      debugging ...
  (eval (with-input-from-string code read) (current-module))
  ...)

SCM entry_point_proc = SCM_VARIABLE_REF (scm_c_lookup ("entry-point"));

scm_call_1 (entry_point_proc, code_string);

The second is that you almost certainly don't want the continuation
call to make C think it is returning again from the first scm_call_1
().  That kind of thing tends to confuse C code :-)

I solved that problem (when I wanted to do something very like what
you're doing) with an approach like this:

(define current-c-code-continuation #f)

(define (entry-point code)
  (call/cc (lambda (k)
             (set! current-c-code-continuation k)

             ... set up ... (as above) ...
             (eval (with- ...) ...)
             ... (as above)

             (current-c-code-continuation))))

> I think (I haven't yet tried) that the above can work if I wrap
> the whole darn thing with scm_with_guile() .. but is there
> some way of getting the above to run without a big wrap
> of this kind?

I don't think the above qualifies as "without a big wrap".  But it did
work.

Regards,
        Neil

Re: continuation barriers

[Linas Vepstas]

Hi Neil.

Wow!

2009/8/26 Neil Jerram <neil@ossau.uklinux.net>:
> Linas Vepstas <linasvepstas@gmail.com> writes:
>
>> i.e. I'd like something like this to work:
>>
>> scm_c_eval_string(" ... (call/cc (lambda (k) (set! *myk* k))) ...");
>> ... some_c_code(...);
>> scm_c_eval_string(" ... (*myk* 42) ...");
>
> I think there are a couple of problems here.
>
> The first is as you've noted, that scm_c_eval_string() has a
> scm_c_with_continuation_barrier() hiding inside it.  You can avoid
> that by using some other method for calling from C into Scheme, for
> example:
>
> (define (entry-point code)
>  ... set up whatever catches you want around the
>      code that is going to be evaluated, e.g. for
>      debugging ...
>  (eval (with-input-from-string code read) (current-module))
>  ...)
>
> SCM entry_point_proc = SCM_VARIABLE_REF (scm_c_lookup ("entry-point"));
>
> scm_call_1 (entry_point_proc, code_string);
>
> The second is that you almost certainly don't want the continuation
> call to make C think it is returning again from the first scm_call_1
> ().  That kind of thing tends to confuse C code :-)
>
> I solved that problem (when I wanted to do something very like what
> you're doing) with an approach like this:
>
> (define current-c-code-continuation #f)
>
> (define (entry-point code)
>  (call/cc (lambda (k)
>             (set! current-c-code-continuation k)
>
>             ... set up ... (as above) ...
>             (eval (with- ...) ...)
>             ... (as above)
>
>             (current-c-code-continuation))))

From what I can tell, I think the above will work for me.  The
"wow" comes from the realization that I'm still not thinking in
a functional kind of way.  Presuming that I can get this working,
I think that I can spend a few hours re-phrasing your email into
an example suitable for the formal guile docs.  If I do, should
I send a patch against guile-docs (wherever these may be?)

>> I think (I haven't yet tried) that the above can work if I wrap
>> the whole darn thing with scm_with_guile() .. but is there
>> some way of getting the above to run without a big wrap
>> of this kind?
>
> I don't think the above qualifies as "without a big wrap".

Yeah, I've discovered its more or less impossible to try to
wrap my main program with an "scm_with_guile()"  Too
 too many dynamically loaded wacko libs opening too many
threads calling to/from god-knows what langauge (java, lua, python...)

--linas

Re: continuation barriers

[Linas Vepstas]

Hi Neil,

2009/8/26 Neil Jerram <neil@ossau.uklinux.net>:
> Linas Vepstas <linasvepstas@gmail.com> writes:
>
>> i.e. I'd like something like this to work:
>>
>> scm_c_eval_string(" ... (call/cc (lambda (k) (set! *myk* k))) ...");
>> ... some_c_code(...);
>> scm_c_eval_string(" ... (*myk* 42) ...");
>
> I think there are a couple of problems here.
>
> The first is as you've noted, that scm_c_eval_string() has a
> scm_c_with_continuation_barrier() hiding inside it.

I mis-spoke or mis-implied -- the thing holding the continuation
barrier is scm_with_guile().  There may also be one within
scm_c_eval_str() although I did not immediately spot it.

> You can avoid
> that by using some other method for calling from C into Scheme, for
> example:

What you described would seem to work, except that what I really
need is a a variant of scm_with_guile() without the continuation
barrier.   Or rather, a variant of scm_with_guile() which uses a
continuation barrier only if the stack underneath is *different*
than what it was when the continuation was defined.  (Right?
since if the stack is the same, using the continuation can't
mess up the stack.)

I think that what I suggest is straightforward to code up: and
I think its safe.  Would anyone care for a patch against 1.9.2 or
1.9.3 or whatever?

--linas