[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Guile 3.0.0 released
Stefan Israelsson Tampe
Re: GNU Guile 3.0.0 released
Thu, 16 Jan 2020 18:56:05 +0100
Actually the change of adding a binding resulted in a change in python on guile. There the python module which is compiled to a minimal lisp (and not tree il) needed to import the else binding.
We are delighted to announce GNU Guile release 3.0.0, the first in the
new 3.0 stable release series.
Compared to the previous stable series (2.2.x), Guile 3.0 adds support
for just-in-time native code generation, speeding up all Guile programs.
See the NEWS extract at the end of the mail for full details.
The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a copy of the Guile manual and pointers
to more resources.
Guile is an implementation of the Scheme programming language, packaged
for use in a wide variety of environments. In addition to implementing
the R5RS, R6RS, and R7RS Scheme standards, Guile includes full access to
POSIX system calls, networking support, multiple threads, dynamic
linking, a foreign function call interface, powerful string processing,
and HTTP client and server implementations.
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 3.0.0 can be installed in parallel with Guile 2.2.x; see
A more detailed NEWS summary follows these details on how to get the
Here are the compressed sources:
Here are the GPG detached signatures[*]:
Use a mirror for higher download bandwidth:
Here are the SHA256 checksums:
[*] 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-3.0.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 4FD4D288D445934E0A14F9A5A8803732E4436885
and rerun the 'gpg --verify' command.
This release was bootstrapped with the following tools:
An extract from NEWS follows.
Changes in 3.0.0 (since the stable 2.2 series):
* Notable changes
** Just-in-time code generation
Guile programs now run up to 4 times faster, relative to Guile 2.2,
thanks to just-in-time (JIT) native code generation. Notably, this
brings the performance of "eval" as written in Scheme back to the level
of "eval" written in C, as in the days of Guile 1.8.
See "Just-In-Time Native Code" in the manual, for more information. JIT
compilation will be enabled automatically and transparently. To disable
JIT compilation, configure Guile with `--enable-jit=no' or
`--disable-jit'. The default is `--enable-jit=auto', which enables the
JIT if it is available. See `./configure --help' for more.
JIT compilation is enabled by default on x86-64, i686, ARMv7, and
** Lower-level bytecode
Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
is now more low-level. This allows it to express more advanced
optimizations, for example type check elision or integer
devirtualization, and makes the task of JIT code generation easier.
Note that this change can mean that for a given function, the
corresponding number of instructions in Guile 3.0 may be higher than
Guile 2.2, which can lead to slowdowns when the function is interpreted.
We hope that JIT compilation more than makes up for this slight
** Interleaved internal definitions and expressions allowed
It used to be that internal definitions had to precede all expressions
in their bodies. This restriction has been relaxed. If an _expression_
precedes an internal definition, it is treated as if it were a
definition of an unreferenced variable. For example, the _expression_
`(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
if it precedes other definitions.
This change improves the readability of Guile programs, as it used to be
that program indentation tended to increase needlessly to allow nested
`let' and `letrec' to re-establish definition contexts after initial
expressions, for example for type-checks on procedure arguments.
** Record unification
Guile used to have a number of implementations of structured data types
in the form of "records": a core facility, SRFI-9 (records), SRFI-35
(condition types -- a form of records) and R6RS records. These
facilities were not compatible, as they all were built in different
ways. This had the unfortunate corollary that SRFI-35 conditions were
not compatible with R6RS conditions. To fix this problem, we have now
added the union of functionality from all of these record types into
core records: single-inheritance subtyping, mutable and immutable
fields, and so on. See "Records" in the manual, for full details.
R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
have been accordingly "rebased" on top of core records.
** Reimplementation of exceptions
Since Guile's origins 25 years ago, `throw' and `catch' have been the
primary exception-handling primitives. However these primitives have
two problems. One is that it's hard to handle exceptions in a
structured way using `catch'. Few people remember what the
corresponding `key' and `args' are that an exception handler would see
in response to a call to `error', for example. In practice, this
results in more generic catch-all exception handling than one might
The other problem is that `throw', `catch', and especially
`with-throw-handler' are quite unlike what the rest of the Scheme world
uses. R6RS and R7RS, for example, have mostly converged on
SRFI-34-style `with-exception-handler' and `raise' primitives, and
encourage the use of SRFI-35-style structured exception objects to
describe the error. Guile's R6RS layer incorporates an adapter between
`throw'/`catch' and structured exception handling, but it didn't apply
to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
In light of these considerations, Guile has now changed to make
`with-exception-handler' and `raise-exception' its primitives for
exception handling and defined a hierarchy of R6RS-style exception types
in its core. SRFI-34/35, R6RS, and the exception-handling components of
SRFI-18 (threads) have been re-implemented in terms of this core
functionality. There is also a a compatibility layer that makes it so
that exceptions originating in `throw' can be handled by
`with-exception-hander', and vice-versa for `raise-exception' and
Generally speaking, users will see no difference. The one significant
difference is that users of SRFI-34 will see more exceptions flowing
through their `with-exception-handler'/`guard' forms, because whereas
before they would only see exceptions thrown by SRFI-34, now they will
see exceptions thrown by R6RS, R7RS, or indeed `throw'.
Guile's situation is transitional. Most exceptions are still signalled
via `throw'. These will probably migrate over time to
`raise-exception', while preserving compatibility of course.
See "Exceptions" in the manual, for full details on the new API.
** `guard' no longer unwinds the stack for clause tests
SRFI-34, and then R6RS and R7RS, defines a `guard' form that is a
shorthand for `with-exception-handler'. The cond-like clauses for the
exception handling are specified to run with the continuation of the
`guard', while any re-propagation of the exception happens with the
continuation of the original `raise'.
In practice, this means that one needs full `call-with-continuation' to
implement the specified semantics, to be able to unwind the stack to the
cond clauses, then rewind if none match. This is not only quite
expensive, it is also error-prone as one usually doesn't want to rewind
dynamic-wind guards in an exceptional situation. Additionally, as
continuations bind tightly to the current thread, it makes it impossible
to migrate a subcomputation with a different thread if a `guard' is live
on the stack, as is done in Fibers.
Guile now works around these issues by running the test portion of the
guard expressions within the original `raise' continuation, and only
unwinding once a test matches. This is an incompatible semantic change
but we think the situation is globally much better, and we expect that
very few people will be affected by the change.
** Optimization of top-level bindings within a compilation unit
At optimization level 2 and above, Guile's compiler is now allowed to
inline top-level definitions within a compilation unit. See
"Declarative Modules" in the manual, for full details. This change can
improve the performance of programs with many small top-level
definitions by quite a bit!
At optimization level 3 and above, Guile will assume that any top-level
binding in a declarative compilation unit that isn't exported from a
module can be completely inlined into its uses. (Prior to this change,
-O3 was the same as -O2.) Note that with this new
`seal-private-bindings' pass, private declarative bindings are no longer
available for access from the first-class module reflection API. The
optimizations afforded by this pass can be useful when you need a speed
boost, but having them enabled at optimization level 3 means they are
not on by default, as they change Guile's behavior in ways that users
might not expect.
** By default, GOOPS classes are not redefinable
It used to be that all GOOPS classes were redefinable, at least in
theory. This facility was supported by an indirection in all "struct"
instances, even though only a subset of structs would need redefinition.
We wanted to remove this indirection, in order to speed up Guile
records, allow immutable Guile records to eventually be described by
classes, and allow for some optimizations in core GOOPS classes that
shouldn't be redefined anyway.
Thus in GOOPS now there are classes that are redefinable and classes
that aren't. By default, classes created with GOOPS are not
redefinable. To make a class redefinable, it should be an instance of
`<redefinable-class>'. See "Redefining a Class" in the manual for more
** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
These auxiliary syntax definitions are specified to be defined in the
R6RS and the R7RS. They were previously unbound, even in the R6RS
modules. This change is not anticipated to cause any incompatibility
with existing Guile code, and improves things for R6RS and R7RS users.
** Conventional gettext alias is now `G_'
Related to the last point, since the "Fix literal matching for
module-bound literals" change in the 2.2 series, it was no longer
possible to use the conventional `_' binding as an alias for `gettext',
because a local `_' definition would prevent `_' from being recognized
as auxiliary syntax for `match', `syntax-rules', and similar. The new
recommended conventional alias for `gettext' is `G_'.
** Add --r6rs command-line option
The new `install-r6rs!' procedure adapts Guile's defaults to be more
R6RS-compatible. This procedure is called if the user passes `--r6rs'
as a command-line argument. See "R6RS Incompatibilities" in the manual,
for full details.
** Add support for R7RS
Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
modules. As the R7RS library syntax is a subset of R6RS, to use R7RS
you just `(import (scheme base))' and off you go. As with R6RS also,
there are some small lexical incompatibilities regarding hex escapes;
see "R6RS Support" in the manual, for full details.
Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
** Add #:re-export-and-replace argument to `define-module'
This new keyword specifies a set of bindings to re-export, but also
marks them as intended to replace core bindings. See "Creating Guile
Modules" in the manual, for full details.
Note to make this change, we had to change the way replacement flags are
stored, to being associated with modules instead of individual variable
objects. This means that users who #:re-export an imported binding that
was already marked as #:replace by another module will now see warnings,
as they need to use #:re-export-and-replace instead.
** `define-module' #:autoload no longer pulls in the whole module
One of the ways that a module can use another is "autoloads". For
(define-module (a) #:autoload (b) (make-b))
In this example, module `(b)' will only be imported when the `make-b'
identifier is referenced. However besides the imprecision about when a
given binding is actually referenced, this mechanism used to cause the
whole imported module to become available, not just the specified
bindings. This has now been changed to only import the specified bindings.
This is a backward-incompatible change. The fix is to mention all
bindings of interest in the autoload clause. Feedback is welcome.
** Improve SRFI-43 vector-fill!
SRFI-43 vector-fill! now has the same performance whether an optional
range is provided or not, and is also provided in core. As a side
effect, vector-fill! and vector_fill_x no longer work on non-vector
rank-1 arrays. Such cases were handled incorrectly before; for example,
prior to this change:
(define a (make-vector 10 'x))
(define b (make-shared-array a (lambda (i) (list (* 2 i))) 5))
(vector-fill! b 'y)
=> #1(y y y x x)
This is now an error. Instead, use array-fill!.
** `iota' in core and SRFI-1 `iota' are the same
Previously, `iota' in core would not accept start and step arguments and
would return an empty list for negative count. Now there is only one
`iota' function with the extended semantics of SRFI-1. Note that as an
incompatible change, core `iota' no longer accepts a negative count.
** Improved Transport Layer Security (TLS) support in (web client)
`http-request', `http-get', and related procedures from (web client) are
able to access content over TLS ("HTTPS") since Guile 2.2. However,
that support lacked important facilities, which are now available.
First, these procedures now have a #:verify-certificates? parameter to
enable or disable the verification of X.509 server certificates. The
new `x509-certificate-directory' SRFI-39 parameter specifies X.509
certificates are searched for. Second, HTTPS proxies are now supported
(in addition to HTTP proxies) and the new `current-https-proxy'
parameter controls that. See "Web Client" in the manual for details.
* New deprecations
** scm_t_uint8, etc deprecated in favor of C99 stdint.h
It used to be that Guile defined its own `scm_t_uint8' because C99
`uint8_t' wasn't widely enough available. Now Guile finally made the
change to use C99 types, both internally and in Guile's public headers.
Note that this also applies to SCM_T_UINT8_MAX, SCM_T_INT8_MIN, for intN
and uintN for N in 8, 16, 32, and 64. Guile also now uses ptrdiff_t
instead of scm_t_ptrdiff, and similarly for intmax_t, uintmax_t,
intptr_t, and uintptr_t.
** The two-argument form of `record-constructor'
Calling `record-constructor' with two arguments (the record type and a
list of field names) is deprecated. Instead, call with just one
argument, and provide a wrapper around that constructor if needed.
* Incompatible changes
** All deprecated code removed
All code deprecated in Guile 2.2 has been removed. See older NEWS, and
check that your programs can compile without linker warnings and run
without runtime warnings. See "Deprecation" in the manual.
In particular, the function `scm_generalized_vector_get_handle' which
was deprecated in 2.0.9 but remained in 2.2, has now finally been
removed. As a replacement, use `scm_array_get_handle' to get a handle
and `scm_array_handle_rank' to check the rank.
** Remove "self" field from vtables and "redefined" field from classes
These fields were used as part of the machinery for class redefinition
and is no longer needed.
** VM hook manipulation simplified
The low-level mechanism to instrument a running virtual machine for
debugging and tracing has been simplified. See "VM Hooks" in the
manual, for more.
* Changes to the distribution
** New effective version
The "effective version" of Guile is now 3.0, which allows parallel
installation with other effective versions (for example, the older Guile
2.2). See "Parallel Installations" in the manual for full details.
Notably, the `pkg-config' file is now `guile-3.0', and there are new
`guile-3' and `guile-3.0' features for `cond-expand'.
- GNU Guile 3.0.0 released, Andy Wingo, 2020/01/16
- Re: GNU Guile 3.0.0 released,
Stefan Israelsson Tampe <=
- Re: GNU Guile 3.0.0 released, Taylan Kammer, 2020/01/16
- Re: GNU Guile 3.0.0 released, Arne Babenhauserheide, 2020/01/16
- Re: GNU Guile 3.0.0 released, Ludovic Courtès, 2020/01/18
- Re: GNU Guile 3.0.0 released, Stefan Israelsson Tampe, 2020/01/21
- Re: GNU Guile 3.0.0 released, Stefan Israelsson Tampe, 2020/01/27