GNU Guile 1.9.15 released — last call before 2.0!

[Ludovic Courtès]

We are pleased to announce GNU Guile release 1.9.15.  This is the last
pre-release before the 2.0 release, due on Feb. 16th!

It provides many new noteworthy features, most notably the addition of a
compiler and virtual machine.  We encourage you to test them 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 link to the Guile FAQ and pointers to
the mailing lists.

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 and
a large subset of R6RS, 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.


Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/guile/guile-1.9.15.tar.gz   (5.3MB)

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

To reduce load on the main server, use a mirror listed at:
  http://www.gnu.org/order/ftp.html

Here are the MD5 and SHA1 checksums:

e42ace49a05dcaccb24a264a16646194  guile-1.9.15.tar.gz
0b1cdd5f0506dcda3ed85324b2a0ff510920ee76  guile-1.9.15.tar.gz

[*] You can use either of the above signature files 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-1.9.15.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 EA52ECF4

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.68
  Automake 1.11.1
  Libtool 2.4
  Gnulib v0.0-4544-gce083ca


This is a new release series with many new features and differences
compared to 1.8.  The complete list of changes compared to the 1.8.x
series is available in the `NEWS' file.

  Changes in 1.9.15 (since the 1.9.14 prerelease):

  ** Formally deprecate omission of port to `format'

  It used to be that you could omit passing a port to `format', in some
  cases.  This still works, but has been formally deprecated.

  ** ECMAScript fixes

  Noah Lavine and Kan-Ru Chen noticed and fixed a number of embarrassing
  bugs in object creation, unicode literals in strings, empty function
  bodies, non-breaking whitespace, and numeric literals.

  ** `(web ...)' changes

  *** `parse-uri', `unparse-uri' now called `string->uri', `uri->string'

  *** `uri-decode' takes `#:encoding' keyword argument, not `#:charset'

  *** HTTP header representation change

  Guile properly garbage-collects symbols, so there's no need to read some
  headers as symbols and some as strings: all header names are symbols
  now.  The same goes for many key-value constructs in headers.  Guile
  parses the challenge/authentication headers now, as well.  Header decl
  objects are no longer exposed to the user.

  *** Request and response bodies are always bytevectors

  Reading bodies as latin-1 strings was a cute hack, but not general, so
  Guile's only official fetch-me-the-body procedures return bytevectors
  now.

  ** New procedures: scm_{to,from}_{utf8,latin1}_symbol{n,}
  ** New procedures: scm_{to,from}_{utf8,utf32,latin1}_symbol{n,}

  These new procedures convert to and from string representations in
  particular encodings.

  Basically, continue to use locale encoding for user input, user output,
  or interacting with the C library.  Use latin1 for ASCII, and for
  literals in source code.  Use utf8 for interaction with modern libraries
  which deal in UTF-8.  Use utf32 for interaction with utf32-using
  libraries.  Otherwise use scm_to_stringn or scm_from_stringn with a
  specific encoding.

  Also, scm_from_latin1_symbol is quite a bit faster now.

  ** Documentation updates

  The GOOPS manual saw a lot of work, as well as documentation for the
  `(web ...)' modules.

  ** Guile uses iconv directly for reading from and writing to ports.

  In addition to providing faster Unicode I/O (e.g., `display',
  `read-char'), this change improves error reporting.

  For instance, the `encoding-error' exception conveys information about
  the port and character that could not be encoded.  Likewise, the new
  `decoding-error' exception conveys information about the port from which
  data failed to be decoded, and leaves the port in a known position.

  ** Source files default to UTF-8.

  If source files do not specify their encoding via a `coding:' block,
  the default encoding is UTF-8, instead of being taken from the current
  locale.

  ** Man page updates

  Thanks to Mark Harig for many suggestions regarding the manual page,
  which is getting better.

  ** Interactive Guile installs the current locale.

  Instead of leaving the user in the "C" locale, running the Guile REPL
  installs the current locale.

  ** `recv!', `recvfrom!', `send', `sendto' now deal in bytevectors

  These socket procedures now take bytevectors as arguments, instead of
  strings.  There is some deprecated string support, however.

  ** New foreign API: `define-wrapped-pointer-type', `pointer?'

  See "Foreign Types", for more.

  ** Changes and bugfixes in numerics code

  *** Added two new sets of fast quotient and remainder operators

  Added two new sets of fast quotient and remainder operator pairs with
  different semantics than the R5RS operators.  They support not only
  integers, but all reals, including exact rationals and inexact
  floating point numbers.

  These procedures accept two real numbers N and D, where the divisor D
  must be non-zero.  `euclidean-quotient' returns the integer Q and
  `euclidean-remainder' returns the real R such that N = Q*D + R and
  0 <= R < |D|.  `euclidean/' returns both Q and R, and is more
  efficient than computing each separately.  Note that when D > 0,
  `euclidean-quotient' returns floor(N/D), and when D < 0 it returns
  ceiling(N/D).

  `centered-quotient', `centered-remainder', and `centered/' are similar
  except that the range of remainders is -abs(D/2) <= R < abs(D/2), and
  `centered-quotient' rounds N/D to the nearest integer.

  Note that these operators are equivalent to the R6RS integer division
  operators `div', `mod', `div-and-mod', `div0', `mod0', and
  `div0-and-mod0'.

  *** Complex number changes

  Guile is now able to represent non-real complex numbers whose
  imaginary part is an _inexact_ zero (0.0 or -0.0), per R6RS.
  Previously, such numbers were immediately changed into inexact reals.

  (real? 0.0+0.0i) now returns #f, per R6RS, although (zero? 0.0+0.0i)
  still returns #t, per R6RS.  (= 0 0.0+0.0i) and (= 0.0 0.0+0.0i) are
  #t, but the same comparisons using `eqv?' or `equal?' are #f.

  Like other non-real numbers, these complex numbers with inexact zero
  imaginary part will raise exceptions is passed to procedures requiring
  reals, such as `<', `>', `<=', `>=', `min', `max', `positive?',
  `negative?', `inf?', `nan?', `finite?', etc.

  **** `make-rectangular' changes

  scm_make_rectangular `make-rectangular' now returns a real number only
  if the imaginary part is an _exact_ 0.  Previously, it would return a
  real number if the imaginary part was an inexact zero.

  scm_c_make_rectangular now always returns a non-real complex number,
  even if the imaginary part is zero.  Previously, it would return a
  real number if the imaginary part was zero.

  **** `make-polar' changes

  scm_make_polar `make-polar' now returns a real number only if the
  angle or magnitude is an _exact_ 0.  If the magnitude is an exact 0,
  it now returns an exact 0.  Previously, it would return a real
  number if the imaginary part was an inexact zero.

  scm_c_make_polar now always returns a non-real complex number, even if
  the imaginary part is 0.0.  Previously, it would return a real number
  if the imaginary part was 0.0.

  **** `imag-part' changes

  scm_imag_part `imag-part' now returns an exact 0 if applied to an
  inexact real number.  Previously it returned an inexact zero in this
  case.

  *** `eqv?' and `equal?' now compare numbers equivalently

  scm_equal_p `equal?' now behaves equivalently to scm_eqv_p `eqv?' for
  numeric values, per R5RS.  Previously, equal? worked differently,
  e.g. `(equal? 0.0 -0.0)' returned #t but `(eqv? 0.0 -0.0)' returned #f,
  and `(equal? +nan.0 +nan.0)' returned #f but `(eqv? +nan.0 +nan.0)'
  returned #t.

  *** `(equal? +nan.0 +nan.0)' now returns #t

  Previously, `(equal? +nan.0 +nan.0)' returned #f, although
  `(let ((x +nan.0)) (equal? x x))' and `(eqv? +nan.0 +nan.0)'
  both returned #t.  R5RS requires that `equal?' behave like
  `eqv?' when comparing numbers.

  *** Change in handling products `*' involving exact 0

  scm_product `*' now handles exact 0 differently.  A product containing
  an exact 0 now returns an exact 0 if and only if the other arguments
  are all exact.  An inexact zero is returned if and only if the other
  arguments are all finite but not all exact.  If an infinite or NaN
  value is present, a NaN value is returned.  Previously, any product
  containing an exact 0 yielded an exact 0, regardless of the other
  arguments.

  *** `expt' and `integer-expt' changes when the base is 0

  While `(expt 0 0)' is still 1, and `(expt 0 N)' for N > 0 is still
  zero, `(expt 0 N)' for N < 0 is now a NaN value, and likewise for
  integer-expt.  This is more correct, and conforming to R6RS, but seems
  to be incompatible with R5RS, which would return 0 for all non-zero
  values of N.

  *** `expt' and `integer-expt' are more generic, less strict

  When raising to an exact non-negative integer exponent, `expt' and
  `integer-expt' are now able to exponentiate any object that can be
  multiplied using `*'.  They can also raise an object to an exact
  negative integer power if its reciprocal can be taken using `/'.
  In order to allow this, the type of the first argument is no longer
  checked when raising to an exact integer power.  If the exponent is 0
  or 1, the first parameter is not manipulated at all, and need not
  even support multiplication.

  *** Infinities are no longer integers, nor rationals

  scm_integer_p `integer?' and scm_rational_p `rational?' now return #f
  for infinities, per R6RS.  Previously they returned #t for real
  infinities.  The real infinities and NaNs are still considered real by
  scm_real `real?' however, per R6RS.

  *** NaNs are no longer rationals

  scm_rational_p `rational?' now returns #f for NaN values, per R6RS.
  Previously it returned #t for real NaN values.  They are still
  considered real by scm_real `real?' however, per R6RS.

  *** `inf?' and `nan?' now throw exceptions for non-reals

  The domain of `inf?' and `nan?' is the real numbers.  Guile now signals
  an error when a non-real number or non-number is passed to these
  procedures.  (Note that NaNs _are_ considered numbers by scheme, despite
  their name).

  *** `rationalize' bugfixes and changes

  Fixed bugs in scm_rationalize `rationalize'.  Previously, it returned
  exact integers unmodified, although that was incorrect if the epsilon
  was at least 1 or inexact, e.g. (rationalize 4 1) should return 3 per
  R5RS and R6RS, but previously it returned 4.  It also now handles
  cases involving infinities and NaNs properly, per R6RS.

  *** Trigonometric functions now return exact numbers in some cases

  scm_sin `sin', scm_cos `cos', scm_tan `tan', scm_asin `asin', scm_acos
  `acos', scm_atan `atan', scm_sinh `sinh', scm_cosh `cosh', scm_tanh
  `tanh', scm_sys_asinh `asinh', scm_sys_acosh `acosh', and
  scm_sys_atanh `atanh' now return exact results in some cases.

  *** New procedure: `finite?'

  Add scm_finite_p `finite?' from R6RS to guile core, which returns #t
  if and only if its argument is neither infinite nor a NaN.  Note that
  this is not the same as (not (inf? x)) or (not (infinite? x)), since
  NaNs are neither finite nor infinite.

  *** R6RS base library changes

  **** `div', `mod', `div-and-mod', `div0', `mod0', `div0-and-mod0'

  Efficient versions of these R6RS division operators are now supported.
  See the NEWS entry entitled `Added two new sets of fast quotient and
  remainder operators' for more information.

  **** `infinite?' changes

  `infinite?' and `finite?' now throw exceptions for non-numbers.  (Note
  that NaNs _are_ considered numbers by scheme, despite their name).

  **** `real-valued?', `rational-valued?' and `integer-valued?' changes

  These predicates are now implemented in accordance with R6RS.

  ** R6RS textual I/O procedures raise R6RS error conditions

  R6RS procedures `get-char', `put-string', etc. now raise the correct
  R6RS error coding, i.e., `&i/o-decoding-error' or `&i/o-encoding-error'.

  ** New reader option: `hungry-eol-escapes'

  Guile's string syntax is more compatible with R6RS when the
  `hungry-eol-escapes' option is enabled.  See "String Syntax" in the
  manual, for more information.

  ** And of course, the usual collection of bugfixes

  Interested users should see the ChangeLog for more information.


You can follow Guile development in the Git repository and on the Guile
mailing lists.  Guile builds from the `master' branch of Git have
version number 1.9.x.

Guile versions with an odd middle number, e.g., 1.9.*, are unstable
development versions.  Even middle numbers indicate stable versions.
This has been the case since the 1.3.* series.

Please report bugs to address@hidden'.  We also welcome reports of
successful builds, which can be sent to the same email address.


Ludovic Courtès, on behalf of the Guile team.

pgpjg4ONomic0.pgp
Description: PGP signature