diff --git a/devel/ChangeLog b/devel/ChangeLog index 6d6c09813..b60980387 100644 --- a/devel/ChangeLog +++ b/devel/ChangeLog @@ -1,3 +1,7 @@ +2001-12-04 Gary Houston + + * some discussion in extension/dynamic-root.text. + 2001-11-28 Gary Houston * added extension directory and extension/dynamic-root.text with diff --git a/devel/extension/dynamic-root.text b/devel/extension/dynamic-root.text index edf714f78..184e81940 100644 --- a/devel/extension/dynamic-root.text +++ b/devel/extension/dynamic-root.text @@ -24,5 +24,55 @@ whether a new interface should also be available to Scheme code. Discussion ========== +There are two ways that longjmp may be invoked from a Scheme callback: +raising an exception or invoking a continuation. Exceptions can be +caught using scm_internal_catch, so it could be argued that the new +interface only needs to block continuations. + +However there are two problems with this: firstly it's unlikely that +anybody would want to block continuations without also catching +exceptions, so it's more convenient to use a single facility set up +both types of blocking. Secondly, the fact that exceptions and +continuations can be treated separately in Guile is just an +implementation detail: in general in Scheme it's possible to use +continuations to implement an exception mechanism, and it's +undesirable to tie a new language feature to an implementation detail +when it can be avoided, even at the C level. + +Hence, the interface should take at least a) the callback to be +protected b) and exception handler and associated handler data to be +passed to scm_internal_catch. + +On which side of the continuation barrier should be exception handler +be installed? Logically it belongs on the same side as the callback: +i.e., if the callback raises an exception then the handler can catch +it without crossing it the continuation barrier. But what happens if +the handler raises another exception? This doesn't seem like an +important concern, since the hander is under control of the same C +code that is trying to protect itself. It should be sufficient to +warn in the documentation that such exceptions produce undefined +behaviour and allow them to cross the continuation barrier. + +How should the callback procedure be passed to the interface and +invoked? Should it be like scm_internal_catch where it's passed as a +C procedure (scm_t_catch_body) which is applied to user data (void *)? +For a procedure designed to be used from C, this is the most +convenient, since constructing closures in C is not very convenient. +It also gives symmetry with scm_internal_catch. + +Hence the first four arguments to the C interface should be the same as for +the old scm_internal_cwdr: + +scm_t_catch_body body, void *body_data, +scm_t_catch_handler handler, void *handler_data + +The return value from the interface should be the result of calling +the body, unless an exception occurred in which case it's the result +of calling the handler. So the return type is SCM, as for +scm_internal_catch. + +Yet to be discussed: libguile usage and threads, error handling and +reporting, convenience of use, Scheme-level interface. + Proposal ========