We are delighted to announce GNU Guile release 2.2.0, the first of a new stable release series.
More than 6 years in the making, Guile 2.2 includes a new optimizing compiler and high-performance register virtual machine. Compared to the old 2.0 series, real-world programs often show a speedup of 30% or more with Guile 2.2. Besides the compiler upgrade, Guile 2.2 removes limitations on user programs by lowering memory usage, speeding up the "eval" interpreter, providing better support for multi-core programming, and last but not least, removing any fixed limit on recursive function calls. Not only does Guile 2.2 run fast, it also supports the creation of user-space concurrency facilities that multiplex millions of concurrent lightweight "fibers". See https://www.gnu.org/software/guile/news/gnu-guile-220-released.html for pointers to promising experiments. If you are migrating from earlier versions of Guile, be sure to read the NEWS below for exhaustive information on user-visible changes relative to the previous stable series. Installation instructions follow the NEWS. As a bonus, this release includes a binary release built with Guix that you can untar onto any x86_64 GNU/Linux system and test out Guile for yourself; details at the end of this mail. * * * Guile is an implementation of the Scheme programming language. The Guile web page is located at https://gnu.org/software/guile/, and among other things, it contains a copy of the Guile manual and pointers to more resources. 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 implements many common Scheme standards, including R5RS, R6RS, and a number of SRFIs. In addition, Guile includes its own module system, full access to POSIX system calls, networking support, multiple threads, dynamic linking, a foreign function call interface, and powerful string processing. Guile 2.2.0 can be installed in parallel with Guile 2.0.x; see https://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html. Changes in 2.2.0 (changes since the 2.0.x stable release series): * Notable changes ** Speed The biggest change in Guile 2.2 is a complete rewrite of its virtual machine and compiler internals. The result is faster startup time, better memory usage, and faster execution of user code. See the "Performance improvements" section below for more details. ** Better thread-safety This new release series takes the ABI-break opportunity to fix some interfaces that were difficult to use correctly from multiple threads. Notably, weak hash tables and ports are now transparently thread-safe. See "Scheduling" in the manual, for updated documentation on threads and communications primitives. ** Better space-safety It used to be the case that, when calling a Scheme procedure, the procedure and arguments were always preserved against garbage collection. This is no longer the case; Guile is free to collect the procedure and arguments if they become unreachable, or to re-use their slots for other local variables. Guile still offers good-quality backtraces by determining the procedure being called from the instruction pointer instead of from the value in slot 0 of an application frame, and by using a live variable map that allows the debugger to know which locals are live at all points in a frame. ** Off-main-thread finalization Following Guile 2.0.6's change to invoke finalizers via asyncs, Guile 2.2 takes the additional step of invoking finalizers from a dedicated finalizer thread, if threads are enabled. This avoids concurrency issues between finalizers and application code, and also speeds up finalization. If your application's finalizers are not robust to the presence of threads, see "Foreign Objects" in the manual for information on how to disable automatic finalization and instead run finalizers manually. ** Better locale support in Guile scripts When Guile is invoked directly, either from the command line or via a hash-bang line (e.g. "#!/usr/bin/guile"), it now installs the current locale via a call to `(setlocale LC_ALL "")'. For users with a unicode locale, this makes all ports unicode-capable by default, without the need to call `setlocale' in your program. This behavior may be controlled via the GUILE_INSTALL_LOCALE environment variable; see "Environment Variables" in the manual, for more. ** Complete Emacs-compatible Elisp implementation Thanks to the work of Robin Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love. ** Dynamically expandable stacks Instead of allocating fixed stack sizes for running Scheme code, Guile now starts off each thread with only one page of stack, and expands and shrinks it dynamically as needed. Guile will throw an exception for stack overflows if growing the stack fails. It is also possible to impose a stack limit during the extent of a function call. See "Stack Overflow" in the manual, for more. This change allows users to write programs that use the stack as a data structure for pending computations, as it was meant to be, without reifying that data out to the heap. Where you would previously make a loop that collect its results in reverse order only to re-reverse them at the end, now you can just recurse without worrying about stack overflows. Using the stack also allows more code to be continuation-safe. For example, returning multiple times from a `map' procedure in Guile 2.0 would change the value of previously returned result lists, because `map' built its result list in reverse order then used `reverse!' to return the proper result. Now in Guile 2.2, `map' is implemented using straightforward recursion, which eliminates this bug while maintaining good performance as well as good space complexity. ** Out-of-memory improvements Instead of aborting, failures to allocate memory will now raise an unwind-only `out-of-memory' exception, and cause the corresponding `catch' expression to run garbage collection in order to free up memory. ** GOOPS core reimplemented in Scheme Guile's object orientation system, GOOPS, has been mostly reimplemented in Scheme. This decreases its maintenance burden on the rest of Guile, while also makes it possible to implement new features in the future, such as method combinations or `eqv?' specializers. ** Better handling of GUILE_LOAD_COMPILED_PATH It used to be that Guile would stop at the first .go file it found in the GUILE_LOAD_COMPILED_PATH. If that file turned out to be out of date, then no .go file would be loaded. Now Guile will continue to search the path for a file which is both present and up-to-date, with respect to the .scm file. ** C99 required Following Emacs, you must use a C99-capable compiler when building Guile. In the future we also expect require C99 to use Guile's C interface, at least for `stdint' support. ** Lightweight pre-emptive threading primitives The compiler now inserts special "handle-interrupts" opcodes before each call, return, and backwards jump target. This allows the user to interrupt any computation and to accurately profile code using interrupts. It used to be that interrupts were run by calling a C function from the VM; now interrupt thunks are run directly from the VM. This allows interrupts to save a delimited continuation and, if the continuation was established from the same VM invocation (the usual restriction), that continuation can then be resumed. In this way users can implement lightweight pre-emptive threading facilities. ** with-dynamic-state in VM Similarly, `with-dynamic-state' no longer recurses out of the VM, allowing captured delimited continuations that include a `with-dynamic-state' invocation to be resumed. This is a precondition to allow lightweight threading libraries to establish a dynamic state per lightweight fiber. * Performance improvements ** Faster programs via new virtual machine Guile now compiles programs to instructions for a new virtual machine. The new virtual machine's instructions can address their source and destination operands by "name" (slot). This makes access to named temporary values much faster than in Guile 2.0, and removes a lot of value-shuffling that the old virtual machine had to do. The end result is that loop-heavy code can be two or three times as fast with Guile 2.2 as in 2.0. Your mileage may vary, of course; see "A Virtual Machine for Guile" in the manual for the nitties and the gritties. ** Better startup time, memory usage with ELF object file format Guile now uses the standard ELF format for its compiled code. (Guile has its own loader and linker, so this does not imply a dependency on any particular platform's ELF toolchain.) The benefit is that Guile is now able to statically allocate more data in the object files. ELF also enables more sharing of data between processes, and decreases startup time (about 40% faster than the already fast startup of the Guile 2.0 series). Guile also uses DWARF for some of its debugging information. Much of the debugging information can be stripped from the object files as well. See "Object File Format" in the manual, for full details. ** Better optimizations via compiler rewrite Guile's compiler now uses a Continuation-Passing Style (CPS) intermediate language, allowing it to reason easily about temporary values and control flow. Examples of optimizations that this permits are optimal contification, optimal common subexpression elimination, dead code elimination, loop-invariant code motion, loop peeling, loop inversion, parallel moves with at most one temporary, allocation of stack slots using precise liveness information, unboxing of 64-bit integers and floating point values, and closure optimization. For more, see "Continuation-Passing Style" in the manual. ** Faster interpreter Combined with a number of optimizations to the interpreter itself, simply compiling `eval.scm' with the new compiler yields an interpreter that is consistently two or three times faster than the one in Guile 2.0. ** Allocation-free dynamic stack Guile now implements the dynamic stack with an actual stack instead of a list of heap objects, avoiding most allocation. This speeds up prompts, the `scm_dynwind_*' family of functions, fluids, and `dynamic-wind'. ** Optimized UTF-8 and Latin-1 ports, symbols, and strings Guile 2.2 is faster at reading and writing UTF-8 and Latin-1 strings from ports, and at converting symbols and strings to and from these encodings. ** Optimized hash functions Guile 2.2 now uses Bob Jenkins' `hashword2' (from his `lookup3.c') for its string hash, and Thomas Wang's integer hash function for `hashq' and `hashv'. These functions produce much better hash values across all available fixnum bits. ** Optimized generic array facility Thanks to work by Daniel Llorens, the generic array facility is much faster now, as it is internally better able to dispatch on the type of the underlying backing store. ** All ports are now buffered, can be targets of `setvbuf' See "Buffering" in the manual, for more. A port with a buffer size of 1 is equivalent to an unbuffered port. Ports may set their default buffer sizes, and some ports (for example soft ports) are unbuffered by default for historical reasons. ** Mutexes are now faster under contention Guile implements its own mutexes, so that threads that are trying to acquire a mutex can be interrupted. These mutexes used to be quite inefficient when many threads were trying to acquire them, causing many spurious wakeups and contention. This has been fixed. * New interfaces ** New `cond-expand' feature: `guile-2.2' Use this feature if you need to check for Guile 2.2 from Scheme code. ** New predicate: `nil?' See "Nil" in the manual. ** New compiler modules Since the compiler was rewritten, there are new modules for the back-end of the compiler and the low-level loader and introspection interfaces. See the "Guile Implementation" chapter in the manual for all details. ** Add "tree" display mode for statprof. See the newly updated "Statprof" section of the manual, for more. ** Support for non-blocking I/O See "Non-Blocking I/O" in the manual, for more. ** Implement R6RS custom binary input/output ports See "Custom Ports" in the manual. ** Implement R6RS output-buffer-mode ** Implement R6RS bytevector->string, string->bytevector See "R6RS Transcoders" in the manual. ** `accept' now takes optional flags argument These flags can include `SOCK_NONBLOCK' and `SOCK_CLOEXEC', indicating options to apply to the returned socket, potentially removing the need for additional system calls to set these options. See "Network Sockets and Communication" in the manual, for more. ** Thread-safe atomic boxes (references) See "Atomics" in the manual. ** Thread-local fluids Guile now has support for fluids whose values are not captured by `current-dynamic-state' and not inheritied by child threads, and thus are local to the kernel thread they run on. See "Thread-Local Variables" in the manual, for more. ** suspendable-continuation? This predicate returns true if the delimited continuation captured by aborting to a prompt would be able to be resumed. See "Prompt Primitives" in the manual for more. ** scm_c_prepare_to_wait_on_fd, scm_c_prepare_to_wait_on_cond, ** scm_c_wait_finished See "Asyncs" in the manual for more. ** File descriptor finalizers See "Ports and File Descriptors" in the manual. ** New inline functions: `scm_new_smob', `scm_new_double_smob' These can replace many uses of SCM_NEWSMOB, SCM_RETURN_NEWSMOB2, and the like. See XXX in the manual, for more. ** New low-level type accessors For more on `SCM_HAS_TYP7', `SCM_HAS_TYP7S', `SCM_HAS_TYP16', see XXX. `SCM_HEAP_OBJECT_P' is now an alias for the inscrutable `SCM_NIMP'. `SCM_UNPACK_POINTER' and `SCM_PACK_POINTER' are better-named versions of the old `SCM2PTR' and `PTR2SCM'. Also, `SCM_UNPACK_POINTER' yields a void*. ** `TCP_NODELAY' and `TCP_CORK' socket options, if provided by the system ** `scm_c_put_latin1_chars', `scm_c_put_utf32_chars' Use these instead of `scm_lfwrite'. See the new "Using Ports from C" section of the manual, for more. ** <standard-vtable>, standard-vtable-fields See "Structures" in the manual for more on these. ** Convenience utilities for ports and strings. See "Conversion to/from C" for more on `scm_from_port_string', `scm_from_port_stringn', `scm_to_port_string', and `scm_to_port_stringn'. ** New expressive PEG parser See "PEG Parsing" in the manual for more. Thanks to Michael Lucy for originally writing these, and to Noah Lavine for integration work. ** `make-stack' now also works on delimited continuations ** Better URI-reference support The `(web uri)' module now has interfaces for handling URI references, which might not have a scheme. The Location header of a web request or response is now a URI reference instead of a URI. Also, `request-absolute-uri' now has an optional default scheme argument. See "Web" in the manual for full details. ** formal-name->char, char->formal-name See "Characters", in the manual. * Incompatible changes ** ASCII is not ISO-8859-1 In Guile 2.0, if a user set "ASCII" or "ANSI_X3.4-1968" as the encoding of a port, Guile would treat it as ISO-8859-1. While these encodings are the same for codepoints 0 to 127, ASCII does not extend past that range, whereas ISO-8859-1 goes up to 255. Guile 2.2 no longer treats ASCII as ISO-8859-1. This is likely to be a problem only if the user's locale is set to ASCII, and the user or a program writes non-ASCII codepoints to a port. ** Decoding errors do not advance the read pointer before erroring When the user sets a port's conversion strategy to "error", indicating that Guile should throw an error if it tries to read from a port whose incoming bytes are not valid for the port's encoding, it used to be that Guile would advance the read pointer past the bad bytes, and then throw an error. This would allow the following `read-char' invocation to proceed after the bad bytes. This behavior is incompatible with the final R6RS standard, and besides contravenes the user's intention to raise an error on bad input. Guile now raises an error without advancing the read pointer. To skip over a bad encoding, set the port conversion strategy to "substitute" and read a substitute character. ** Decoding errors with `substitute' strategy return U+FFFD It used to be that decoding errors with the `substitute' conversion strategy would replace the bad bytes with a `?' character. This has been changed to use the standard U+FFFD REPLACEMENT CHARACTER, in accordance with the Unicode recommendations. ** API to define new port types from C has changed Guile's ports have been completely overhauled to allow Guile developers and eventually Guile users to write low-level input and output routines in Scheme. The new internals will eventually allow for user-space tasklets or green threads that suspend to a scheduler when they would cause blocking I/O, allowing users to write straightforward network services that parse their input and send their output as if it were blocking, while under the hood Guile can multiplex many active connections at once. At the same time, this change makes Guile's ports implementation much more maintainable, rationalizing the many legacy port internals and making sure that the abstractions between the user, Guile's core ports facility, and the port implementations result in a system that is as performant and expressive as possible. The interface to the user has no significant change, neither on the C side nor on the Scheme side. However this refactoring has changed the interface to the port implementor in an incompatible way. See the newly expanded "I/O Extensions" in the manual, for full details. *** Remove `scm_set_port_mark' Port mark functions have not been called since the switch to the BDW garbage collector. *** Remove `scm_set_port_equalp' Likewise port equal functions weren't being called. Given that ports have their own internal buffers, it doesn't make sense to hook them into equal? anyway. *** Remove `scm_set_port_free' It used to be that if an open port became unreachable, a special "free" function would be called instead of the "close" function. Now that the BDW-GC collector allows us to run arbitrary code in finalizers, we can simplify to just call "close" on the port and remove the separate free functions. Note that hooking into the garbage collector has some overhead. For that reason Guile exposes a new interface, `scm_set_port_needs_close_on_gc', allowing port implementations to indicate to Guile whether they need closing on GC or not. *** Remove `scm_set_port_end_input', `scm_set_port_flush' As buffering is handled by Guile itself, these functions which were to manage an implementation-side buffer are no longer needed. *** Change prototype of `scm_make_port_type' The `read' (renamed from `fill_input') and `write' functions now operate on bytevectors. Also the `mode_bits' argument now inplicitly includes SCM_OPN, so you don't need to include these. *** Change prototype of port `close' function The port close function now returns void. *** Port and port type data structures are now opaque Port type implementations should now use API to access port state. However, since the change to handle port buffering centrally, port type implementations rarely need to access unrelated port state. *** Port types are now `scm_t_port_type*', not a tc16 value `scm_make_port_type' now returns an opaque pointer, not a tc16. Relatedly, the limitation that there only be 256 port types has been lifted. ** String ports default to UTF-8 Guile 2.0 would use the `%default-port-encoding' when creating string ports. This resulted in ports that could only accept a subset of valid characters, which was surprising to users. Now string ports default to the UTF-8 encoding. Sneaky users can still play encoding conversion games with string ports by explicitly setting the encoding of a port after it is open. See "Ports" in the manual for more. ** `scm_from_stringn' and `scm_to_stringn' encoding arguments are never NULL These functions now require a valid `encoding' argument, and will abort if given `NULL'. ** All r6rs ports are both textual and binary Because R6RS ports are a thin layer on top of Guile's ports, and Guile's ports are both textual and binary, Guile's R6RS ports are also both textual and binary, and thus both kinds have port transcoders. This is an incompatibility with respect to R6RS. ** Threading facilities moved to (ice-9 threads) It used to be that call-with-new-thread and other threading primitives were available in the default environment. This is no longer the case; they have been moved to (ice-9 threads) instead. Existing code will not break, however; we used the deprecation facility to signal a warning message while also providing these bindings in the root environment for the duration of the 2.2 series. ** cancel-thread uses asynchronous interrupts, not pthread_cancel See "Asyncs" in the manual, for more on asynchronous interrupts. ** SRFI-18 threads, mutexes, cond vars disjoint from Guile When we added support for the SRFI-18 threading library in Guile 2.0, we did so in a way that made SRFI-18 mutexes the same as Guile mutexes. This was a mistake. In Guile our goal is to provide basic, well-thought-out, well-implemented, minimal primitives, on top of which we can build a variety of opinionated frameworks. Incorporating SRFI-18 functionality into core Guile caused us to bloat and slow down our core threading primitives. Worse, they became very hard to describe; they did many things, did them poorly, and all that they did was never adequately specified. For all of these reasons we have returned to a situation where SRFI-18 concepts are implemented only in the `(srfi srfi-18)' module. This means that SRFI-18 threads are built on Guile threads, but aren't the same as Guile threads; calling Guile `thread?' on a thread no longer returns true. We realize this causes inconvenience to users who use both Guile threading interfaces and SRFI-18 interfaces, and we lament the change -- but we are better off now. We hope the newly revised "Scheduling" section in the manual compensates for the headache. ** Remove `lock-mutex' "owner" argument Mutex owners are a SRFI-18 concept; use SRFI-18 mutexes instead. Relatedly, `scm_lock_mutex_timed' taking the owner argument is now deprecated; use `scm_timed_lock_mutex' instead. ** Remove `unlock-mutex' cond var and timeout arguments It used to be that `unlock-mutex' included `wait-condition-variable' functionality. This has been deprecated; use SRFI-18 if you want this behavior from `mutex-unlock!'. Relatedly, `scm_unlock_mutex_timed' is deprecated; use `scm_unlock_mutex' instead. ** Removed `unchecked-unlock' mutex flag This flag was introduced for internal use by SRFI-18; use SRFI-18 mutexes if you need this behaviour. ** SRFI-18 mutexes no longer recursive Contrary to specification, SRFI-18 mutexes in Guile were recursive. This is no longer the case. ** Thread cleanup handlers removed The `set-thread-cleanup!' and `thread-cleanup' functions that were added in Guile 2.0 to support cleanup after thread cancellation are no longer needed, since threads can declare cleanup handlers via `dynamic-wind'. ** Only threads created by Guile are joinable `join-thread' used to work on "foreign" threads that were not created by Guile itself, though their join value was always `#f'. This is no longer the case; attempting to join a foreign thread will throw an error. ** Dynamic states capture values, not locations Dynamic states used to capture the locations of fluid-value associations. Capturing the current dynamic state then setting a fluid would result in a mutation of that captured state. Now capturing a dynamic state simply captures the current values, and calling `with-dynamic-state' copies those values into the Guile virtual machine instead of aliasing them in a way that could allow them to be mutated in place. This change allows Guile's fluid variables to be thread-safe. To capture the locations of a dynamic state, capture a `with-dynamic-state' invocation using partial continuations instead. ** Remove `frame-procedure' Several optimizations in Guile make `frame-procedure' an interface that we can no longer support. For background, `frame-procedure' used to return the value at slot 0 in a frame, which usually corresponds to the SCM value of the procedure being applied. However it could be that this slot is re-used for some other value, because the closure was not needed in the function. Such a re-use might even be for an untagged value, in which case treating slot 0 as a SCM value is quite dangerous. It's also possible that so-called "well-known" closures (closures whose callers are all known) are optimized in such a way that slot 0 is not a procedure but some optimized representation of the procedure's free variables. Instead, developers building debugging tools that would like access to `frame-procedure' are invited to look at the source for the `(system vm frame)' module for alternate interfaces, including the new `frame-procedure-name'. ** Remove `,procedure' REPL command Not all procedures have values, so it doesn't make sense to expose this interface to the user. Instead, the `,locals' REPL command will include the callee, if it is live. ** Remove `frame-local-ref', `frame-local-set!', `frame-num-locals' These procedures reference values in a frame on the stack. Since we now have unboxed values of different kinds, it is now necessary to specify the type when reference locals, and once this incompatible change needs to be made, we might as well make these interfaces private. See "Frames' in the manual, for more information on the replacements for these low-level interfaces. ** Vtable hierarchy changes In an attempt to make Guile's structure and record types integrate better with GOOPS by unifying the vtable hierarchy, `make-vtable-vtable' is now deprecated. Instead, users should just use `make-vtable' with appropriate arguments. See "Structures" in the manual for all of the details. As such, `record-type-vtable' and `%condition-type-vtable' now have a parent vtable and are no longer roots of the vtable hierarchy. ** Syntax parameters are a distinct type Guile 2.0's transitional implementation of `syntax-parameterize' was based on the `fluid-let-syntax' interface inherited from the psyntax expander. This interface allowed any binding to be dynamically rebound -- even bindings like `lambda'. This is no longer the case in Guile 2.2. Syntax parameters must be defined via `define-syntax-parameter', and only such bindings may be parameterized. See "Syntax Parameters" in the manual for more. ** Defined identifiers scoped in the current module Sometimes Guile's expander would attach incorrect module scoping information for top-level bindings made by an expansion. For example, given the following R6RS library: (library (defconst) (export defconst) (import (guile)) (define-syntax-rule (defconst name val) (begin (define t val) (define-syntax-rule (name) t)))) Attempting to use it would produce an error: (import (defconst)) (defconst foo 42) (foo) =| Unbound variable: t It wasn't clear that we could fix this in Guile 2.0 without breaking someone's delicate macros, so the fix is only coming out now. ** Pseudo-hygienically rename macro-introduced bindings Bindings introduced by macros, like `t' in the `defconst' example above, are now given pseudo-fresh names. This allows (defconst foo 42) (defconst bar 37) to introduce different bindings for `t'. These pseudo-fresh names are made in such a way that if the macro is expanded again, for example as part of a simple recompilation, the introduced identifiers get the same pseudo-fresh names. See "Hygiene and the Top-Level" in the manual, for details. ** Fix literal matching for module-bound literals `syntax-rules' and `syntax-case' macros can take a set of "literals": bound or unbound keywords that the syntax matcher treats specially. Before, literals were always matched symbolically (by name). Now they are matched by binding. This allows literals to be reliably bound to values, renamed by imports or exports, et cetera. See "Syntax-rules Macros" in the manual for more on literals. ** Fix bug importing specific bindings with #:select It used to be that if #:select didn't find a binding in the public interface of a module, it would actually grovel in the module's unexported private bindings. This was not intended and is now fixed. ** Statically scoped module duplicate handlers It used to be that if a module did not specify a #:duplicates handler, when a name was first referenced in that module and multiple imported modules provide that name, the value of the `default-duplicate-binding-handlers' parameter would be used to resolve the duplicate bindings. We have changed so that instead a module defaults to the set of handlers described in the manual. If the module specifies #:duplicates, of course we use that. The `default-duplicate-binding-handlers' parameter now simply accesses the handlers of the current module, instead of some global value. ** Fix too-broad capture of dynamic stack by delimited continuations Guile was using explicit stacks to represent, for example, the chain of current exception handlers. This means that a delimited continuation that captured a "catch" expression would capture the whole stack of exception handlers, not just the exception handler added by the "catch". This led to strangeness when resuming the continuation in some other context like other threads; "throw" could see an invalid stack of exception handlers. This has been fixed by the addition of the new "fluid-ref*" procedure that can access older values of fluids; in this way the exception handler stack is now implicit. See "Fluids and Dynamic States" in the manual, for more on fluid-ref*. ** `dynamic-wind' doesn't check that guards are thunks Checking that the dynamic-wind out-guard procedure was actually a thunk before doing the wind was slow, unreliable, and not strictly needed. ** All deprecated code removed All code deprecated in Guile 2.0 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. ** Remove miscellaneous unused interfaces We have removed accidentally public, undocumented interfaces that we think are not used, and not useful. This includes `scm_markstream', `SCM_FLUSH_REGISTER_WINDOWS', `SCM_THREAD_SWITCHING_CODE', `SCM_FENCE', `scm_call_generic_0', `scm_call_generic_1', `scm_call_generic_2' `scm_call_generic_3', `scm_apply_generic', and `scm_program_source'. `scm_async_click' was renamed to `scm_async_tick', and `SCM_ASYNC_TICK' was made private (use `SCM_TICK' instead). ** Many internal compiler / VM changes As the compiler and virtual machine were re-written, there are many changes in the back-end of Guile to interfaces that were introduced in Guile 2.0. These changes are only only of interest if you wrote a language on Guile 2.0 or a tool using Guile 2.0 internals. If this is the case, drop by the IRC channel to discuss the changes. ** Defining a SMOB or port type no longer mucks exports of `(oop goops)' It used to be that defining a SMOB or port type added an export to GOOPS, for the wrapper class of the smob type. This violated modularity, though, so we have removed this behavior. ** Bytecode replaces objcode as a target language One way in which people may have used details of Guile's runtime in Guile 2.0 is in compiling code to thunks for later invocation. Instead of compiling to objcode and then calling `make-program', now the way to do it is to compile to `bytecode' and then call `load-thunk-from-memory' from `(system vm loader)'. ** Weak pairs removed Weak pairs were not safe to access with `car' and `cdr', and so were removed. ** Weak alist vectors removed Use weak hash tables instead. ** Weak vectors may no longer be accessed via `vector-ref' et al Weak vectors may no longer be accessed with the vector interface. This was a source of bugs in the 2.0 Guile implementation, and a limitation on using vectors as building blocks for other abstractions. Vectors in Guile are now a concrete type; for an abstract interface, use the generic array facility (`array-ref' et al). ** scm_t_array_implementation removed This interface was introduced in 2.0 but never documented. It was a failed attempt to layer the array implementation that actually introduced too many layers, as it prevented the "vref" and "vset" members of scm_t_array_handle (called "ref" and "set" in 1.8, not present in 2.0) from specializing on array backing stores. Notably, the definition of scm_t_array_handle has now changed, to not include the (undocumented) "impl" member. We are sorry for any inconvenience this may cause. ** `scm_make' is now equivalent to Scheme `make' It used to be that `scm_make' only implemented a hard-wired object allocation and initialization protocol. This was because `scm_make' was used while GOOPS booted its own, more complete `make' implementation in Scheme. Now that we've re-implemented everything in Scheme, the C `scm_make' now dispatches directly to Scheme `make', which implements the full protocol. This change is incompatible in some ways, but on the whole is good news for GOOPS users. ** GOOPS slot definitions are now objects Slot definitions are now instances of a <slot> class, instead of being specially formatted lists. To most user code, this is transparent, as the slot definition accessors like `slot-definition-name' continue to work. However, code that for example uses `car' to get the name of a slot definition will need to be updated to use the accessors. ** Class slot changes Class objects no longer have a `default-slot-definition-class' slot, which was never used. They also no longer have slots for hashsets (`h0', `h1', and so on up to `h7'), which have been unused since Guile 2.0 and were not a great idea. There is a new class option, `#:static-slot-allocation?'. See the manual for details. ** Removal of internal, unintentionally exposed GOOPS C interfaces These include: `scm_sys_fast_slot_ref', `scm_sys_fast_slot_set_x' `scm_basic_basic_make_class', `scm_sys_compute_slots', `scm_sys_prep_layout_x' `scm_t_method', `SCM_METHOD', `scm_s_slot_set_x', `SCM_CLASS_CLASS_LAYOUT', `scm_si_slotdef_class', `scm_si_generic_function', `scm_si_specializers', `scm_si_procedure', `scm_si_formals', `scm_si_body', `scm_si_make_procedure', `SCM_CLASS_CLASS_LAYOUT', `SCM_INSTANCE_HASH', `SCM_SET_HASHSET', `union scm_t_debug_info', `scm_pure_generic_p', `SCM_PUREGENERICP', `SCM_VALIDATE_PUREGENERIC', `SCM_VTABLE_FLAG_GOOPS_PURE_GENERIC', `SCM_CLASSF_PURE_GENERIC', `scm_c_extend_primitive_generic', `scm_sys_initialize_object', `SCM_CLASS_CLASS_LAYOUT', `scm_si_redefined', `scm_si_direct_supers', `scm_si_direct_slots', `scm_si_direct_subclasses', `scm_si_direct_methods', `scm_si_cpl' `scm_si_slots', `scm_si_getters_n_setters', `SCM_N_CLASS_SLOTS', `SCM_OBJ_CLASS_REDEF', `SCM_INST', `SCM_ACCESSORS_OF', `scm_sys_allocate_instance', and `scm_sys_invalidate_class_x'. * New deprecations ** `SCM_FDES_RANDOM_P' Instead, use `lseek (fd, 0, SEEK_CUR)' directly. ** `_IONBF', `_IOLBF', and `_IOFBF' Instead, use the symbol values `none', `line', or `block', respectively, as arguments to the `setvbuf' function. ** `SCM_FDES_RANDOM_P' Instead, use `lseek (fd, 0, SEEK_CUR)' directly. ** Arbiters Arbiters were an experimental mutual exclusion facility from 20 years ago that didn't survive the test of time. Use mutexes or atomic boxes instead. ** User asyncs Guile had (and still has) "system asyncs", which are asynchronous interrupts, and also had this thing called "user asyncs", which was a trivial unused data structure. Now that we have deprecated the old `async', `async-mark', and `run-asyncs' procedures that comprised the "user async" facility, we have been able to clarify our documentation to only refer to "asyncs". ** Critical sections Critical sections have long been just a fancy way to lock a mutex and defer asynchronous interrupts. Instead of SCM_CRITICAL_SECTION_START, make sure you're in a "scm_dynwind_begin (0)" and use scm_dynwind_pthread_mutex_lock instead, possibly also with scm_dynwind_block_asyncs. ** `scm_make_mutex_with_flags' Use `scm_make_mutex_with_kind' instead. See "Mutexes and Condition Variables" in the manual, for more. ** Dynamic roots This was a facility that predated threads, was unused as far as we can tell, and was never documented. Still, a grep of your code for dynamic-root or dynamic_root would not be amiss. ** `make-dynamic-state' Use `current-dynamic-state' to get an immutable copy of the current fluid-value associations. ** `with-statprof' macro Use the `statprof' procedure instead. ** SCM_WTA_DISPATCH_0, SCM_WTA_DISPATCH_1, SCM_WTA_DISPATCH_2, SCM_WTA_DISPATCH_N ** SCM_GASSERT0, SCM_GASSERT1, SCM_GASSERT2, SCM_GASSERTn ** SCM_WTA_DISPATCH_1_SUBR These macros were used in dispatching primitive generics. They can be replaced by using C functions (the same name but in lower case), if needed, but this is a hairy part of Guile that perhaps you shouldn't be using. ** scm_compute_applicable_methods and scm_find_method Use `compute-applicable-methods' from Scheme instead. ** scm_no_applicable_method Fetch no-applicable-method from the GOOPS exports if you need it. ** scm_class_boolean, scm_class_char, scm_class_pair ** scm_class_procedure, scm_class_string, scm_class_symbol ** scm_class_primitive_generic, scm_class_vector, scm_class_null ** scm_class_real, scm_class_complex, scm_class_integer ** scm_class_fraction, scm_class_unknown, scm_class_top ** scm_class_object, scm_class_class, scm_class_applicable ** scm_class_applicable_struct, scm_class_applicable_struct_with_setter ** scm_class_generic, scm_class_generic_with_setter, scm_class_accessor ** scm_class_extended_generic, scm_class_extended_generic_with_setter ** scm_class_extended_accessor, scm_class_method ** scm_class_accessor_method, scm_class_procedure_class ** scm_class_applicable_struct_class, scm_class_number, scm_class_list ** scm_class_keyword, scm_class_port, scm_class_input_output_port ** scm_class_input_port, scm_class_output_port, scm_class_foreign_slot ** scm_class_self, scm_class_protected, scm_class_hidden ** scm_class_opaque, scm_class_read_only, scm_class_protected_hidden ** scm_class_protected_opaque, scm_class_protected_read_only ** scm_class_scm, scm_class_int, scm_class_float, scm_class_double ** scm_port_class, scm_smob_class These class exports are now deprecated. Instead, look up the ones you need from the GOOPS module, or use `scm_class_of' on particular values. ** scm_get_keyword Instead from Scheme use kw-arg-ref or real keyword arguments, and from C use `scm_c_bind_keyword_arguments'. ** scm_slot_ref_using_class, scm_slot_set_using_class_x ** scm_slot_bound_using_class_p, scm_slot_exists_using_class_p Instead use the normal `scm_slot_ref' and similar procedures. * Changes to the distribution ** Pre-built binary files in the tarball Building Guile from a tarball can now take advantage of a "prebuilt/" tree of prebuilt .go files. These compiled files are created when a tarball is made, and are used to speed up the build for users of official releases. These pre-built binaries are not necessary, however: they are not stored in revision control and can always be re-created from the source, given that Guile can bootstrap itself from its minimal bootstrap C interpreter. If you do not want to depend on these pre-built binaries, you can "make -C prebuilt clean" before building. ** New minor version The "effective version" of Guile is now 2.2, which allows parallel installation with other effective versions (for example, the older Guile 2.0). See "Parallel Installations" in the manual for full details. Notably, the `pkg-config' file is now `guile-2.2'. ** Bump required libgc version to 7.2, released March 2012. ** GUILE_PROGS searches for versioned Guile The GUILE_PROGS autoconf macro can take a required version argument. As a new change, that version argument is additionally searched for as a suffix. For example, GUILE_PROGS(2.2) would look for guile-2.2, guile2.2, guile-2, guile2, and then guile. The found prefix is also applied to guild, guile-config, and the like. Thanks to Freja Nordsiek for this work. ** The readline extension is now installed in the extensionsdir The shared library that implements Guile's readline extension is no longer installed to the libdir. This change should be transparent to users, but packagers may be interested. * * * Here are the compressed sources: https://ftp.gnu.org/gnu/guile/guile-2.2.0.tar.gz (17MB) https://ftp.gnu.org/gnu/guile/guile-2.2.0.tar.xz (10MB) https://ftp.gnu.org/gnu/guile/guile-2.2.0.tar.lz (9MB) Here are the GPG detached signatures[*]: https://ftp.gnu.org/gnu/guile/guile-2.2.0.tar.gz.sig https://ftp.gnu.org/gnu/guile/guile-2.2.0.tar.xz.sig https://ftp.gnu.org/gnu/guile/guile-2.2.0.tar.lz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html Here are the SHA256 checksums: ef1e9544631f18029b113911350bffd5064955c208a975bfe0d27a4003d6d86b guile-2.2.0.tar.gz c18198ff6e8b05c620dbdd49b816a2e63a2688af843b5cf8e965041f1adcb515 guile-2.2.0.tar.xz 79fbd7e3b60bc9f8587154972d92f38a0183fbc68b78b66f69e436528eb97b20 guile-2.2.0.tar.lz [*] 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.2.0.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 FF478FB264DE32EC296725A3DDC0F5358812F8F2 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.15 Libtool 2.4.6 Gnulib v0.1-1157-gb03f418 Makeinfo 6.3 * * * Bonus track! This release also contains a new experiment, a binary installation package for the x86_64 architecture. The GNU Guix project (https://guixsd.org/) has assembled a graph of package definitions (for example, GCC, glibc, Guile, and so on) and is able to build that graph in an entirely deterministic way starting from only a handful of trusted bootstrap binaries. Guix recently added a "guix pack" facility that can export build products from a Guix system, including all run-time dependencies. We have used the new "guix pack" to generate an experimental binary distribution for the Guile 2.2.0 release. If you are on an x86_64 system running GNU/Linux, begin by running the following commands: wget https://ftp.gnu.org/gnu/guile/guile-2.2.0-pack-x86_64-linux-gnu.tar.lz wget https://ftp.gnu.org/gnu/guile/guile-2.2.0-pack-x86_64-linux-gnu.tar.lz.sig gpg --verify guile-2.2.0-pack-x86_64-linux-gnu.tar.lz.sig If verification fails, then see above for instructions on how to import the appropriate GPG key. For reference, the pack's sha256sum is: c707b9cf6f97ecca3a4e3e704e62b83f95f1aec28ed1535f5d0a1d36af07a015 guile-2.2.0-pack-x86_64-linux-gnu.tar.lz Then in your root directory -- yes! -- do: cd / sudo tar xvf path/to/guile-2.2.0-pack-x86_64-linux-gnu.tar.lz This tarball will extract some paths into /gnu/store and also add a /opt/guile-2.2.0 symlink. To run Guile, just invoke: /opt/guile-2.2.0/bin/guile Voilà! This binary release was made with the following command: guix pack -C lzip -S /opt/guile-2.2.0=/ guile-next glibc-utf8-locales It was built using Guix development version 80a725726d3b3a62c69c9f80d35a898dcea8ad90. Note that if you run that Guile, it will complain about not being able to install the locale. Guix, like Scheme, is generally a statically scoped system, but it dynamically scopes the set of available locales. That is to say, you have to set GUIX_LOCPATH=/opt/guile-2.2.0/lib/locale in the environment, for locales to work. See the GUIX_LOCPATH docs at https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html for full details. Alternately of course you can install Guix and just guix package -i guile-next. Guix itself will migrate to 2.2 over the next week or so. * * * We hope you enjoy the release (and the bonus track!). Happy hacking with Guile 2.2! Andy, Ludovic, Mark, and the whole Guile team
