[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Guile-commits] branch master updated: Update NEWS with details on guard

From: Andy Wingo
Subject: [Guile-commits] branch master updated: Update NEWS with details on guard and autoloads.
Date: Fri, 10 Jan 2020 16:09:43 -0500

This is an automated email from the git hooks/post-receive script.

wingo pushed a commit to branch master
in repository guile.

The following commit(s) were added to refs/heads/master by this push:
     new 640eb5d  Update NEWS with details on guard and autoloads.
640eb5d is described below

commit 640eb5d1b3c65eb86dff4fee5646c668b43bf02c
Author: Andy Wingo <address@hidden>
AuthorDate: Fri Jan 10 22:09:17 2020 +0100

    Update NEWS with details on guard and autoloads.
    * NEWS: Update.
 NEWS | 63 ++++++++++++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 46 insertions(+), 17 deletions(-)

diff --git a/NEWS b/NEWS
index 4fb91c8..a03b2f7 100644
--- a/NEWS
+++ b/NEWS
@@ -7,13 +7,54 @@ Please send Guile bug reports to address@hidden.
 Changes since alpha 2.9.8:
-** Fix performance of SRFI-43 vector-fill!
+* Notable changes
+** `define-module' #:autoload no longer pulls in the whole module
+One of the ways that a module can use another is "autoloads".  For
+  (define-module (a) #:autoload (b) (make-b))
+In this example, module `(b)' will only be imported when the `make-b'
+identifier is referenced.  However besides the imprecision about when a
+given binding is actually referenced, this mechanism used to cause the
+whole imported module to become available, not just the specified
+bindings.  This has now been changed to only import the specified bindings.
+This is a backward-incompatible change.  The fix is to mention all
+bindings of interest in the autoload clause.  Feedback is welcome.
+** `guard' no longer unwinds the stack for clause tests
+SRFI-34, and then R6RS and R7RS, defines a `guard' form that is a
+shorthand for `with-exception-handler'.  The cond-like clauses for the
+exception handling are specified to run with the continuation of the
+`guard', while any re-propagation of the exception happens with the
+continuation of the original `raise'.
+In practice, this means that one needs full `call-with-continuation' to
+implement the specified semantics, to be able to unwind the stack to the
+cond clauses, then rewind if none match.  This is not only quite
+expensive, it is also error-prone as one usually doesn't want to rewind
+dynamic-wind guards in an exceptional situation.  Additionally, as
+continuations bind tightly to the current thread, it makes it impossible
+to migrate a subcomputation with a different thread if a `guard' is live
+on the stack, as is done in Fibers.
+Guile now works around these issues by running the test portion of the
+guard expressions within the original `raise' continuation, and only
+unwinding once a test matches.  This is an incompatible semantic change
+but we think the situation is globally much better, and we expect that
+very few people will be affected by the change.
+** Improve SRFI-43 vector-fill!
 SRFI-43 vector-fill! now has the same performance whether an optional
 range is provided or not, and is also provided in core.  As a side
 effect, vector-fill! and vector_fill_x no longer work on non-vector
-rank-1 arrays. Such cases were handled incorrectly before; for example,
-prior to this change,
+rank-1 arrays.  Such cases were handled incorrectly before; for example,
+prior to this change:
   (define a (make-vector 10 'x))
   (define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
@@ -21,21 +62,9 @@ prior to this change,
   => #1(y y y x x)
-This is now an error. Instead, use array-fill! (or array_fill_x).
-Changes in alpha 2.9.8 (since alpha 2.9.7):
-* Bug fixes
-** Fix bug in which abort_to_prompt used an invalid stack pointer
-This bug manifested itself as a bootstrap compile error on some systems,
-notably Ubuntu 18.04 on x86-64, and was due to failing to recalculate a
-local variable after a possible stack relocation.
+This is now an error.  Instead, use array-fill!.
-** SRFI-35 does a #:re-export-and-replace on `&error'
-** SRFI-35 avoids compiler warnings for multiply-defined condition types
 Changes in alpha 2.9.x (since the stable 2.2 series):

reply via email to

[Prev in Thread] Current Thread [Next in Thread]