summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--devel/ChangeLog84
-rw-r--r--devel/extension/dynamic-root.text86
2 files changed, 0 insertions, 170 deletions
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 <ttn@giblet.glug.org>
-
- * build/pre-inst-guile.text: Initial revision.
-
-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
- a description of the problem.
-
-2001-11-14 Thien-Thi Nguyen <ttn@giblet.glug.org>
-
- * policy/api.text: Initial revision.
-
-2001-11-12 mvo <mvo@giblet.glug.org>
-
- * translation/lisp-and-scheme.text:
- *** empty log message ***
-
-2001-07-07 mvo <mvo@giblet.glug.org>
-
- * policy/goals.text: Sneak in the translators...
-
-2001-06-27 Thien-Thi Nguyen <ttn@revel.glug.org>
-
- * README: Remove tasks.text.
-
- * tasks.text: Bye bye (contents folded into ../TODO).
-
-2001-05-08 Martin Grabmueller <mgrabmue@cs.tu-berlin.de>
-
- * 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 <mgrabmue@cs.tu-berlin.de>
-
- * modules/module-snippets.texi: New file, documenting the module
- system. Placed in `devel' for review purposes.
-
-2001-03-16 Martin Grabmueller <mgrabmue@cs.tu-berlin.de>
-
- * modules: New directory.
-
- * modules/module-layout.text: New file.
-
-2000-08-26 Mikael Djurfeldt <mdj@linnaeus.mit.edu>
-
- * strings: New directory.
-
- * strings/sharedstr.text (sharedstr.text): New file.
-
-2000-08-12 Mikael Djurfeldt <mdj@linnaeus.mit.edu>
-
- * translate: New directory.
-
- * translate/langtools.text: New file.
-
-2000-05-30 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
-
- * tasks.text: Use outline-mode. Added section for tasks in need
- of attention.
-
-2000-05-29 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
-
- * tasks.text: New file.
-
-2000-05-25 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
-
- * README: New file.
-
- * build/snarf-macros.text: New file.
-
-2000-05-20 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
-
- * policy/goals.text, policy/principles.text, policy/plans.text:
- New files.
-
-2000-03-21 Mikael Djurfeldt <mdj@thalamus.nada.kth.se>
-
- * 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.