GNU Guile 2.1.1 released [beta]

[Andy Wingo]

We are pleased to announce GNU Guile release 2.1.1.  This is the first
pre-release of what will eventually become the 2.2 release series.  It
provides many improvements, most notably in speed: it starts up faster
than Guile 2.0, runs your programs faster, and uses less memory; see
below for full details.  We encourage you to test this release and
provide feedback to address@hidden

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a copy of the Guile manual and pointers
to more resources.  Special thanks to Luis Felipe López Acevedo for the
new site design, also released today; we hope you enjoy it.

Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.

Guile 2.1.1 can be installed in parallel with Guile 2.0.x; see
http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html.

A more detailed NEWS summary follows these details on how to get the
Guile sources.  Note that compiling Guile takes about an hour if you
compile with -j4 or so, as the compilation has to bootstrap itself from
a small interpreter written in C.  It's worth it, though!

Here are the compressed sources:
  http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.gz   (7.4MB)
  http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.xz   (4.6MB)

Here are the GPG detached signatures[*]:
  http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.gz.sig
  http://alpha.gnu.org/gnu/guile/guile-2.1.1.tar.xz.sig

Use a mirror for higher download bandwidth:
  http://www.gnu.org/order/ftp.html

Here are the MD5 and SHA1 checksums:

784d512ab62e885af1708242f06cda18  guile-2.1.1.tar.gz
ded0680f4c2caf49315efda80fb9e292  guile-2.1.1.tar.xz
bcb2ea6ab606b52ac469d79ec17c6a2652cdd66f  guile-2.1.1.tar.gz
6781aa27db3d16eb8972842d24dbfd69f3256f77  guile-2.1.1.tar.xz

[*] 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.1.1.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 8812F8F2

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-92-g546ff82
  Makeinfo 6.0


Changes in 2.1.1 (changes since the 2.0.x 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 are now transparently thread-safe.  Ports are
also thread-safe; see "New interfaces" below for details on the changes
to the C interface.

** 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 the
manual for more.

** Complete Emacs-compatible Elisp implementation

Thanks to the work of BT 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.

* 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, 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.

* 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.

** New functions: `scm_to_intptr_t', `scm_from_intptr_t'
** New functions: `scm_to_uintptr_t', `scm_from_uintptr_t'

See "Integers" in the manual, for more.

** New thread-safe port API

For details on `scm_c_make_port', `scm_c_make_port_with_encoding',
`scm_c_lock_port', `scm_c_try_lock_port', `scm_c_unlock_port',
`scm_c_port_type_ref', `scm_c_port_type_add_x', `SCM_PORT_DESCRIPTOR',
and `scm_dynwind_lock_port', see XXX.

There is now a routine to atomically adjust port "revealed counts".  See
XXX for more on `scm_adjust_port_revealed_x' and
`adjust-port-revealed!',

All other port API now takes the lock on the port if needed.  There are
some C interfaces if you know that you don't need to take a lock; see
XXX for details on `scm_get_byte_or_eof_unlocked',
`scm_peek_byte_or_eof_unlocked' `scm_c_read_unlocked',
`scm_getc_unlocked' `scm_unget_byte_unlocked', `scm_ungetc_unlocked',
`scm_ungets_unlocked', `scm_fill_input_unlocked' `scm_putc_unlocked',
`scm_puts_unlocked', and `scm_lfwrite_unlocked'.

** 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*.

** <standard-vtable>, standard-vtable-fields

See "Structures" in the manual for more on these

** Convenience utilities for ports and strings.

See XXX 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.

** 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.

** 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.

** `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_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

** 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.

** 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.

signature.asc
Description: PGP signature