* some discussion in extension/dynamic-root.text.

devel/ChangeLog

@@ -1,3 +1,7 @@
+2001-12-04  Gary Houston  <ghouston@arglist.com>
+
+	* some discussion in extension/dynamic-root.text.
+
 2001-11-28  Gary Houston  <ghouston@arglist.com>
 
 	* added extension directory and extension/dynamic-root.text with

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
 ========