I can't make a simple case out of this. But the gist is that we have a module c (define-module (c) #:export (fail)) (define fail (cons 'fail '())) Then in module b: (define-module (b) #:use-module (c) #:export (f)) (define-syntax-rule (kif it p x y) (let ((it p)) (if (eq? it fail) y x))) (define (f x) (kif it (x) it x)) Module b is too simple and this compiles, I have a more advanced module and uses of the tag fail. Now this module compiles when we have the definition of fail in the same module but separating it out to module c lead to the fopllowing stack trace: Backtrace: In system/base/compile.scm: 155:11 19 (_ #) 224:14 18 (read-and-compile _ #:from _ #:to _ #:env _ #:opts _) 175:2 17 (compile _ #:from _ #:to _ #:env _ #:opts _) 183:32 16 (compile-fold _ _ _ (#:to-file? #t #:warnings (# # # …))) In language/cps/compile-bytecode.scm: 699:12 15 (compile-bytecode _ # …) In language/cps/closure-conversion.scm: 885:7 14 (convert-closures _) In language/cps/intmap.scm: 519:5 13 (visit-branch #(#(#(# …) …) …) …) 519:5 12 (visit-branch #(#(# …) …) …) 519:5 11 (visit-branch #(# …) …) In language/cps/intset.scm: 470:5 10 (visit-branch #(#(#(#(1064828927 3623737183 …) …) …) …) …) 470:5 9 (visit-branch #(#(#(1064828927 3623737183 # # # …) …) …) …) 470:5 8 (visit-branch #(#(3047188480 218316806 1799356468 …) …) …) 470:5 7 (visit-branch #(213200 #f 1073741824 4294287363 # # # …) …) 470:5 6 (visit-branch 4093640703 _ 2688 _) In language/cps/closure-conversion.scm: 749:15 5 (_ 2705 _) 771:22 4 (lp # …) 771:22 3 (lp # …) 771:22 2 (lp # …) 610:11 1 (allocate-closure _ _ _ _ _ 1) In ice-9/boot-9.scm: 1655:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1655:16: In procedure raise-exception: unexpected well-known nullary, unary, or binary closure Makefile:1295: recipe for target 'oop/pf-objects.go' failed make: *** [oop/pf-objects.go] Error 1 On Thu, Jan 2, 2020 at 2:37 PM Andy Wingo wrote: > We are pleased to announce GNU Guile release 2.9.8. This is the eighth > and possibly final pre-release of what will eventually become the 3.0 > release series. > > Compared to the current stable series (2.2.x), the future Guile 3.0 adds > support for just-in-time native code generation, speeding up all Guile > programs. See the NEWS extract at the end of the mail for full details. > > Compared to the previous prerelease (2.9.7), Guile 2.9.8 fixes a bug in > libguile that caused writes to unmapped memory in some circumstances. > This problem manifested itself as a failure of Guile to compile itself > on some systems, notably Ubuntu 18.04 on x86-64. It also fixes a couple > warnings related to SRFI-35. > > The current plan is to make a 3.0.0 final release on 17 January 2020. > We may need another prerelease in the interim. It's a good time to test > the prereleases to make sure they work on your platform. Please send > any build reports (success or failure) to guile-devel@gnu.org, along > with platform details. You can file a bug by sending mail to > bug-guile@gnu.org. > > The Guile web page is located at http://gnu.org/software/guile/, and > among other things, it contains a copy of the Guile manual and pointers > to more resources. > > Guile is an implementation of the Scheme programming language, with > support for many SRFIs, packaged for use in a wide variety of > environments. In addition to implementing the R5RS Scheme standard, > Guile includes a module system, full access to POSIX system calls, > networking support, multiple threads, dynamic linking, a foreign > function call interface, and powerful string processing. > > Guile can run interactively, as a script interpreter, and as a Scheme > compiler to VM bytecode. It is also packaged as a library so that > applications can easily incorporate a complete Scheme interpreter/VM. > An application can use Guile as an extension language, a clean and > powerful configuration language, or as multi-purpose "glue" to connect > primitives provided by the application. It is easy to call Scheme code > From C code and vice versa. Applications can add new functions, data > types, control structures, and even syntax to Guile, to create a > domain-specific language tailored to the task at hand. > > Guile 2.9.8 can be installed in parallel with Guile 2.2.x; see > > http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html > . > > A more detailed NEWS summary follows these details on how to get the > Guile sources. > > Here are the compressed sources: > http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz (10MB) > http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz (12MB) > http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz (21MB) > > Here are the GPG detached signatures[*]: > http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.lz.sig > http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.xz.sig > http://alpha.gnu.org/gnu/guile/guile-2.9.8.tar.gz.sig > > Use a mirror for higher download bandwidth: > http://www.gnu.org/order/ftp.html > > Here are the SHA256 checksums: > > 3ce11e9dca0f475fa944729d99f33c379fe8962e729bd21a99470249624c71d7 > guile-2.9.8.tar.lz > 4a8cf663b8bfd435168935c74a8ec434328ffad16230322c64f0ac567dda2c26 > guile-2.9.8.tar.xz > 31c3d458ff9342db130e27c8d82d2a33912da92845e5ee431b6a125971a823d2 > guile-2.9.8.tar.gz > > [*] Use a .sig file to verify that the corresponding file (without the > .sig suffix) is intact. First, be sure to download both the .sig file > and the corresponding tarball. Then, run a command like this: > > gpg --verify guile-2.9.8.tar.gz.sig > > If that command fails because you don't have the required public key, > then run this command to import it: > > gpg --keyserver keys.gnupg.net --recv-keys > 4FD4D288D445934E0A14F9A5A8803732E4436885 > > and rerun the 'gpg --verify' command. > > This release was bootstrapped with the following tools: > Autoconf 2.69 > Automake 1.16.1 > Libtool 2.4.6 > Gnulib v0.1-1157-gb03f418 > Makeinfo 6.5 > > An extract from NEWS follows. > > > 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. > > ** 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): > > * Notable changes > > ** Just-in-time code generation > > Guile programs now run up to 4 times faster, relative to Guile 2.2, > thanks to just-in-time (JIT) native code generation. Notably, this > brings the performance of "eval" as written in Scheme back to the level > of "eval" written in C, as in the days of Guile 1.8. > > See "Just-In-Time Native Code" in the manual, for more information. JIT > compilation will be enabled automatically and transparently. To disable > JIT compilation, configure Guile with `--enable-jit=no' or > `--disable-jit'. The default is `--enable-jit=auto', which enables the > JIT if it is available. See `./configure --help' for more. > > JIT compilation is enabled by default on x86-64, i686, ARMv7, and > AArch64 targets. > > ** Lower-level bytecode > > Relative to the virtual machine in Guile 2.2, Guile's VM instruction set > is now more low-level. This allows it to express more advanced > optimizations, for example type check elision or integer > devirtualization, and makes the task of JIT code generation easier. > > Note that this change can mean that for a given function, the > corresponding number of instructions in Guile 3.0 may be higher than > Guile 2.2, which can lead to slowdowns when the function is interpreted. > We hope that JIT compilation more than makes up for this slight > slowdown. > > ** Interleaved internal definitions and expressions allowed > > It used to be that internal definitions had to precede all expressions > in their bodies. This restriction has been relaxed. If an expression > precedes an internal definition, it is treated as if it were a > definition of an unreferenced variable. For example, the expression > `(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))', > if it precedes other definitions. > > This change improves the readability of Guile programs, as it used to be > that program indentation tended to increase needlessly to allow nested > `let' and `letrec' to re-establish definition contexts after initial > expressions, for example for type-checks on procedure arguments. > > ** Record unification > > Guile used to have a number of implementations of structured data types > in the form of "records": a core facility, SRFI-9 (records), SRFI-35 > (condition types -- a form of records) and R6RS records. These > facilities were not compatible, as they all were built in different > ways. This had the unfortunate corollary that SRFI-35 conditions were > not compatible with R6RS conditions. To fix this problem, we have now > added the union of functionality from all of these record types into > core records: single-inheritance subtyping, mutable and immutable > fields, and so on. See "Records" in the manual, for full details. > > R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types > have been accordingly "rebased" on top of core records. > > ** Reimplementation of exceptions > > Since Guile's origins 25 years ago, `throw' and `catch' have been the > primary exception-handling primitives. However these primitives have > two problems. One is that it's hard to handle exceptions in a > structured way using `catch'. Few people remember what the > corresponding `key' and `args' are that an exception handler would see > in response to a call to `error', for example. In practice, this > results in more generic catch-all exception handling than one might > like. > > The other problem is that `throw', `catch', and especially > `with-throw-handler' are quite unlike what the rest of the Scheme world > uses. R6RS and R7RS, for example, have mostly converged on > SRFI-34-style `with-exception-handler' and `raise' primitives, and > encourage the use of SRFI-35-style structured exception objects to > describe the error. Guile's R6RS layer incorporates an adapter between > `throw'/`catch' and structured exception handling, but it didn't apply > to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS. > > In light of these considerations, Guile has now changed to make > `with-exception-handler' and `raise-exception' its primitives for > exception handling and defined a hierarchy of R6RS-style exception types > in its core. SRFI-34/35, R6RS, and the exception-handling components of > SRFI-18 (threads) have been re-implemented in terms of this core > functionality. There is also a a compatibility layer that makes it so > that exceptions originating in `throw' can be handled by > `with-exception-hander', and vice-versa for `raise-exception' and > `catch'. > > Generally speaking, users will see no difference. The one significant > difference is that users of SRFI-34 will see more exceptions flowing > through their `with-exception-handler'/`guard' forms, because whereas > before they would only see exceptions thrown by SRFI-34, now they will > see exceptions thrown by R6RS, R7RS, or indeed `throw'. > > Guile's situation is transitional. Most exceptions are still signalled > via `throw'. These will probably migrate over time to > `raise-exception', while preserving compatibility of course. > > See "Exceptions" in the manual, for full details on the new API. > > ** Optimization of top-level bindings within a compilation unit > > At optimization level 2 and above, Guile's compiler is now allowed to > inline top-level definitions within a compilation unit. See > "Declarative Modules" in the manual, for full details. This change can > improve the performance of programs with many small top-level > definitions by quite a bit! > > At optimization level 3 and above, Guile will assume that any top-level > binding in a declarative compilation unit that isn't exported from a > module can be completely inlined into its uses. (Prior to this change, > -O3 was the same as -O2.) Note that with this new > `seal-private-bindings' pass, private declarative bindings are no longer > available for access from the first-class module reflection API. The > optimizations afforded by this pass can be useful when you need a speed > boost, but having them enabled at optimization level 3 means they are > not on by default, as they change Guile's behavior in ways that users > might not expect. > > ** By default, GOOPS classes are not redefinable > > It used to be that all GOOPS classes were redefinable, at least in > theory. This facility was supported by an indirection in all "struct" > instances, even though only a subset of structs would need redefinition. > We wanted to remove this indirection, in order to speed up Guile > records, allow immutable Guile records to eventually be described by > classes, and allow for some optimizations in core GOOPS classes that > shouldn't be redefined anyway. > > Thus in GOOPS now there are classes that are redefinable and classes > that aren't. By default, classes created with GOOPS are not > redefinable. To make a class redefinable, it should be an instance of > `'. See "Redefining a Class" in the manual for more > information. > > ** Define top-level bindings for aux syntax: `else', `=>', `...', `_' > > These auxiliary syntax definitions are specified to be defined in the > R6RS and the R7RS. They were previously unbound, even in the R6RS > modules. This change is not anticipated to cause any incompatibility > with existing Guile code, and improves things for R6RS and R7RS users. > > ** Conventional gettext alias is now `G_' > > Related to the last point, since the "Fix literal matching for > module-bound literals" change in the 2.2 series, it was no longer > possible to use the conventional `_' binding as an alias for `gettext', > because a local `_' definition would prevent `_' from being recognized > as auxiliary syntax for `match', `syntax-rules', and similar. The new > recommended conventional alias for `gettext' is `G_'. > > ** Add --r6rs command-line option > > The new `install-r6rs!' procedure adapts Guile's defaults to be more > R6RS-compatible. This procedure is called if the user passes `--r6rs' > as a command-line argument. See "R6RS Incompatibilities" in the manual, > for full details. > > ** Add support for R7RS > > Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS > modules. As the R7RS library syntax is a subset of R6RS, to use R7RS > you just `(import (scheme base))' and off you go. As with R6RS also, > there are some small lexical incompatibilities regarding hex escapes; > see "R6RS Support" in the manual, for full details. > > Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs' > command-line option. > > ** Add #:re-export-and-replace argument to `define-module' > > This new keyword specifies a set of bindings to re-export, but also > marks them as intended to replace core bindings. See "Creating Guile > Modules" in the manual, for full details. > > Note to make this change, we had to change the way replacement flags are > stored, to being associated with modules instead of individual variable > objects. This means that users who #:re-export an imported binding that > was already marked as #:replace by another module will now see warnings, > as they need to use #:re-export-and-replace instead. > > ** `iota' in core and SRFI-1 `iota' are the same > > Previously, `iota' in core would not accept start and step arguments and > would return an empty list for negative count. Now there is only one > `iota' function with the extended semantics of SRFI-1. Note that as an > incompatible change, core `iota' no longer accepts a negative count. > > * New deprecations > > ** scm_t_uint8, etc deprecated in favor of C99 stdint.h > > It used to be that Guile defined its own `scm_t_uint8' because C99 > `uint8_t' wasn't widely enough available. Now Guile finally made the > change to use C99 types, both internally and in Guile's public headers. > > Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN > and uintN for N in 8, 16, 32, and 64. Guile also now uses ptrdiff_t > instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t, > intptr_t, and uintptr_t. > > ** The two-argument form of `record-constructor' > > Calling `record-constructor' with two arguments (the record type and a > list of field names) is deprecated. Instead, call with just one > argument, and provide a wrapper around that constructor if needed. > > * Incompatible changes > > ** All deprecated code removed > > All code deprecated in Guile 2.2 has been removed. See older NEWS, and > check that your programs can compile without linker warnings and run > without runtime warnings. See "Deprecation" in the manual. > > In particular, the function `scm_generalized_vector_get_handle' which > was deprecated in 2.0.9 but remained in 2.2, has now finally been > removed. As a replacement, use `scm_array_get_handle' to get a handle > and `scm_array_handle_rank' to check the rank. > > ** Remove "self" field from vtables and "redefined" field from classes > > These fields were used as part of the machinery for class redefinition > and is no longer needed. > > ** VM hook manipulation simplified > > The low-level mechanism to instrument a running virtual machine for > debugging and tracing has been simplified. See "VM Hooks" in the > manual, for more. > > * Changes to the distribution > > ** New effective version > > The "effective version" of Guile is now 3.0, which allows parallel > installation with other effective versions (for example, the older Guile > 2.2). See "Parallel Installations" in the manual for full details. > Notably, the `pkg-config' file is now `guile-3.0', and there are new > `guile-3' and `guile-3.0' features for `cond-expand'. > >