Re: GNU Guile 2.2.0 released

[Nala Ginrut <nalaginrut@gmail.com>]

Congrats!
6 years, well I never realized it. At that time I was a newbie in Scheme land...

Best regards.


On Thu, Mar 16, 2017 at 6:16 PM, Andy Wingo <wingo@pobox.com> wrote:
> 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
>