diff --git a/devel/ChangeLog b/devel/ChangeLog index 70ffefe55..e69de29bb 100644 --- a/devel/ChangeLog +++ b/devel/ChangeLog @@ -1,84 +0,0 @@ -2002-02-05 Thien-Thi Nguyen - - * build/pre-inst-guile.text: Initial revision. - -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 - a description of the problem. - -2001-11-14 Thien-Thi Nguyen - - * policy/api.text: Initial revision. - -2001-11-12 mvo - - * translation/lisp-and-scheme.text: - *** empty log message *** - -2001-07-07 mvo - - * policy/goals.text: Sneak in the translators... - -2001-06-27 Thien-Thi Nguyen - - * README: Remove tasks.text. - - * tasks.text: Bye bye (contents folded into ../TODO). - -2001-05-08 Martin Grabmueller - - * modules/module-snippets.texi: Fixed a lot of typos and clarified - some points. Thanks to Neil for the typo+questions patch! - -2001-05-07 Martin Grabmueller - - * modules/module-snippets.texi: New file, documenting the module - system. Placed in `devel' for review purposes. - -2001-03-16 Martin Grabmueller - - * modules: New directory. - - * modules/module-layout.text: New file. - -2000-08-26 Mikael Djurfeldt - - * strings: New directory. - - * strings/sharedstr.text (sharedstr.text): New file. - -2000-08-12 Mikael Djurfeldt - - * translate: New directory. - - * translate/langtools.text: New file. - -2000-05-30 Mikael Djurfeldt - - * tasks.text: Use outline-mode. Added section for tasks in need - of attention. - -2000-05-29 Mikael Djurfeldt - - * tasks.text: New file. - -2000-05-25 Mikael Djurfeldt - - * README: New file. - - * build/snarf-macros.text: New file. - -2000-05-20 Mikael Djurfeldt - - * policy/goals.text, policy/principles.text, policy/plans.text: - New files. - -2000-03-21 Mikael Djurfeldt - - * policy/names.text: New file. - diff --git a/devel/extension/dynamic-root.text b/devel/extension/dynamic-root.text index 87d351854..e69de29bb 100644 --- a/devel/extension/dynamic-root.text +++ b/devel/extension/dynamic-root.text @@ -1,86 +0,0 @@ -The Problem -=========== - -Certain applications embedding Guile (Scwm, Guppi) have found it -necessary to include hacked versions of scm_call_with_dynamic_root. - -They want to run user callbacks, but don't want the callback to be -able to longjmp (via exceptions or continuations) randomly in and out, -since the C code hasn't been written to dynamically wind/unwind local -state. This is likely to be a common problem for users of Guile as an -extension language. - -libguile/root.c:scm_call_with_dynamic_root seems to almost do this, -but it has the apparently undesirable behaviour of unwinding the -dynamic state when the protected procedure is called. In addition -the implementation looks a bit heavy for use in every callback. - -scm_call_with_dynamic_root was implemented to support threading, so -the needs of libguile itself should be considered. Other -considerations are how any new interface interacts with error handling -and reporting; whether a new interface is convenient to use from C; -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 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 difficult. It also -gives symmetry with scm_internal_catch. - -On the other hand, the body procedure is expected to be a Scheme -closure in most cases. This suggests implementing two C procedures, -the first taking four arguments: - -scm_t_catch_body body, void *body_data, -scm_t_catch_handler handler, void *handler_data - -and the second taking three arguments: -SCM body, scm_t_catch_handler handler, void *handler_data - -If there is also to be a Scheme interface, then it would be implemented -with a third variant: -SCM body, SCM handler - -The second and third variants would be implemented by calling the -first, similar to the old scm_call_with_dynamic_root and its wrappers. - -The return value from all variants 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.