Sorry for the delayed response.
Mark H Weaver writes:
> > Moreover, SRFI-111 boxes and guile variable objects are clearly
> > semantically the same thing.
> Unfortunately, they are not quite the same thing. Unlike SRFI-111
> boxes, Guile variables are a union type: they contain an arbitrary
> S
Trivial patch implementing this suggestion attached.
--- a/module/srfi/srfi-111.scm
+++ b/module/srfi/srfi-111.scm
@@ -17,21 +17,9 @@
;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
(define-module (srfi srfi-111)
- #:use-module (srfi srfi-9)
- #:use-module (srf
Currently, guile's (srfi srfi-111) module ("mutable boxes") provides
an implementation based on records with a single value field.
Wouldn't it make more sense to re-export the functions make-variable,
variable?, variable-ref and variable-set! from the guile core as box,
box?, unbox and set-box! re
The section on the (rnrs lists) library in the guile manual contains the
following:
Scheme Procedure: fold-left combine nil list1 list2 …
Scheme Procedure: fold-right combine nil list1 list2 …
These procedures are identical to the fold and fold-right procedures
provided by SRFI-1.
In the c
The following patch fixes a typo in the guile texinfo docs,
see https://bugs.debian.org/765286 for more info.
--- a/doc/ref/api-data.texi
+++ b/doc/ref/api-data.texi
@@ -5849,7 +5849,7 @@ of the form @code{:NAME} are read as symbols, as required
by R5RS.
@cindex SRFI-88 keyword syntax
-If th
Calling strerror with a non-integer argument causes guile to hang.
e.g.:
(strerror 1.5)
It's a locking issue, which is solved by the following trivial patch:
--- a/libguile/error.c
+++ b/libguile/error.c
@@ -121,10 +121,12 @@ SCM_DEFINE (scm_strerror, "strerror", 1, 0, 0,
#define FUNC_NAME s_sc
