Re: GNU Guile 3.0.0 released

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 19474 bytes --]

Many thanks wingo and team, really great work!!

On Thu, Jan 16, 2020 at 6:56 PM Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> 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.
>
> Den tor 16 jan 2020 12:04Andy Wingo <wingo@pobox.com> skrev:
>
>> 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
>>
>> http://www.gnu.org/software/guile/manual/html_node/Parallel-Installations.html
>> .
>>
>> A more detailed NEWS summary follows these details on how to get the
>> Guile sources.
>>
>> Here are the compressed sources:
>>   http://ftp.gnu.org/gnu/guile/guile-3.0.0.tar.lz   (10MB)
>>   http://ftp.gnu.org/gnu/guile/guile-3.0.0.tar.xz   (12MB)
>>   http://ftp.gnu.org/gnu/guile/guile-3.0.0.tar.gz   (21MB)
>>
>> Here are the GPG detached signatures[*]:
>>   http://ftp.gnu.org/gnu/guile/guile-3.0.0.tar.lz.sig
>>   http://ftp.gnu.org/gnu/guile/guile-3.0.0.tar.xz.sig
>>   http://ftp.gnu.org/gnu/guile/guile-3.0.0.tar.gz.sig
>>
>> Use a mirror for higher download bandwidth:
>>   http://www.gnu.org/order/ftp.html
>>
>> Here are the SHA256 checksums:
>>
>>   e28c450d11f7335769f607214f9b79547400881ddbbc9805ccf3ce2121aa97e0
>> guile-3.0.0.tar.lz
>>   c9138d6595a9f69bf9733d0bc2d3b9f3d8b79f35f289006912b3361cb0510c75
>> guile-3.0.0.tar.xz
>>   049b286849fa9764fac781071c4ec9daef707da51e5050ffb498d7bf6422da2f
>> guile-3.0.0.tar.gz
>>
>> [*] Use a .sig file to verify that the corresponding file (without the
>> .sig suffix) is intact.  First, be sure to download both the .sig file
>> and the corresponding tarball.  Then, run a command like this:
>>
>>   gpg --verify guile-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:
>>   Autoconf 2.69
>>   Automake 1.16.1
>>   Libtool 2.4.6
>>   Gnulib v0.1-1157-gb03f418
>>   Makeinfo 6.7
>>
>> 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
>> AArch64 targets.
>>
>> ** Lower-level bytecode
>>
>> Relative to the virtual machine in Guile 2.2, Guile's VM instruction set
>> is now more low-level.  This allows it to express more advanced
>> optimizations, for example type check elision or integer
>> devirtualization, and makes the task of JIT code generation easier.
>>
>> Note that this change can mean that for a given function, the
>> corresponding number of instructions in Guile 3.0 may be higher than
>> Guile 2.2, which can lead to slowdowns when the function is interpreted.
>> We hope that JIT compilation more than makes up for this slight
>> slowdown.
>>
>> ** Interleaved internal definitions and expressions allowed
>>
>> It used to be that internal definitions had to precede all expressions
>> in their bodies.  This restriction has been relaxed.  If an expression
>> precedes an internal definition, it is treated as if it were a
>> definition of an unreferenced variable.  For example, the expression
>> `(foo)' transforms to the equivalent of `(define _ (begin (foo) #f))',
>> if it precedes other definitions.
>>
>> This change improves the readability of Guile programs, as it used to be
>> that program indentation tended to increase needlessly to allow nested
>> `let' and `letrec' to re-establish definition contexts after initial
>> expressions, for example for type-checks on procedure arguments.
>>
>> ** Record unification
>>
>> Guile used to have a number of implementations of structured data types
>> in the form of "records": a core facility, SRFI-9 (records), SRFI-35
>> (condition types -- a form of records) and R6RS records.  These
>> facilities were not compatible, as they all were built in different
>> ways.  This had the unfortunate corollary that SRFI-35 conditions were
>> not compatible with R6RS conditions.  To fix this problem, we have now
>> added the union of functionality from all of these record types into
>> core records: single-inheritance subtyping, mutable and immutable
>> fields, and so on.  See "Records" in the manual, for full details.
>>
>> R6RS records, SRFI-9 records, and the SRFI-35 and R6RS exception types
>> have been accordingly "rebased" on top of core records.
>>
>> ** Reimplementation of exceptions
>>
>> Since Guile's origins 25 years ago, `throw' and `catch' have been the
>> primary exception-handling primitives.  However these primitives have
>> two problems.  One is that it's hard to handle exceptions in a
>> structured way using `catch'.  Few people remember what the
>> corresponding `key' and `args' are that an exception handler would see
>> in response to a call to `error', for example.  In practice, this
>> results in more generic catch-all exception handling than one might
>> like.
>>
>> The other problem is that `throw', `catch', and especially
>> `with-throw-handler' are quite unlike what the rest of the Scheme world
>> uses.  R6RS and R7RS, for example, have mostly converged on
>> SRFI-34-style `with-exception-handler' and `raise' primitives, and
>> encourage the use of SRFI-35-style structured exception objects to
>> describe the error.  Guile's R6RS layer incorporates an adapter between
>> `throw'/`catch' and structured exception handling, but it didn't apply
>> to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS.
>>
>> In light of these considerations, Guile has now changed to make
>> `with-exception-handler' and `raise-exception' its primitives for
>> exception handling and defined a hierarchy of R6RS-style exception types
>> in its core.  SRFI-34/35, R6RS, and the exception-handling components of
>> SRFI-18 (threads) have been re-implemented in terms of this core
>> functionality.  There is also a a compatibility layer that makes it so
>> that exceptions originating in `throw' can be handled by
>> `with-exception-hander', and vice-versa for `raise-exception' and
>> `catch'.
>>
>> Generally speaking, users will see no difference.  The one significant
>> difference is that users of SRFI-34 will see more exceptions flowing
>> through their `with-exception-handler'/`guard' forms, because whereas
>> before they would only see exceptions thrown by SRFI-34, now they will
>> see exceptions thrown by R6RS, R7RS, or indeed `throw'.
>>
>> Guile's situation is transitional.  Most exceptions are still signalled
>> via `throw'.  These will probably migrate over time to
>> `raise-exception', while preserving compatibility of course.
>>
>> See "Exceptions" in the manual, for full details on the new API.
>>
>> ** `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
>> information.
>>
>> ** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
>>
>> These auxiliary syntax definitions are specified to be defined in the
>> R6RS and the R7RS.  They were previously unbound, even in the R6RS
>> modules.  This change is not anticipated to cause any incompatibility
>> with existing Guile code, and improves things for R6RS and R7RS users.
>>
>> ** Conventional gettext alias is now `G_'
>>
>> Related to the last point, since the "Fix literal matching for
>> module-bound literals" change in the 2.2 series, it was no longer
>> possible to use the conventional `_' binding as an alias for `gettext',
>> because a local `_' definition would prevent `_' from being recognized
>> as auxiliary syntax for `match', `syntax-rules', and similar.  The new
>> recommended conventional alias for `gettext' is `G_'.
>>
>> ** Add --r6rs command-line option
>>
>> The new `install-r6rs!' procedure adapts Guile's defaults to be more
>> R6RS-compatible.  This procedure is called if the user passes `--r6rs'
>> as a command-line argument.  See "R6RS Incompatibilities" in the manual,
>> for full details.
>>
>> ** Add support for R7RS
>>
>> Thanks to Göran Weinholt and OKUMURA Yuki, Guile now implements the R7RS
>> modules.  As the R7RS library syntax is a subset of R6RS, to use R7RS
>> you just `(import (scheme base))' and off you go.  As with R6RS also,
>> there are some small lexical incompatibilities regarding hex escapes;
>> see "R6RS Support" in the manual, for full details.
>>
>> Also as with R6RS, there is an `install-r7rs!' procedure and a `--r7rs'
>> command-line option.
>>
>> ** Add #:re-export-and-replace argument to `define-module'
>>
>> This new keyword specifies a set of bindings to re-export, but also
>> marks them as intended to replace core bindings.  See "Creating Guile
>> Modules" in the manual, for full details.
>>
>> Note to make this change, we had to change the way replacement flags are
>> stored, to being associated with modules instead of individual variable
>> objects.  This means that users who #:re-export an imported binding that
>> was already marked as #:replace by another module will now see warnings,
>> as they need to use #:re-export-and-replace instead.
>>
>> ** `define-module' #:autoload no longer pulls in the whole module
>>
>> One of the ways that a module can use another is "autoloads".  For
>> example:
>>
>>   (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'.
>>
>>

[-- Attachment #2: Type: text/html, Size: 22306 bytes --]