GNU Guile 1.9.11 released (beta)

GNU Guile 1.9.11 released (beta)

[Ludovic Courtès]

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

We are pleased to announce GNU Guile release 1.9.11.  This may be the
last pre-release before the 2.0 release.

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 `guile-devel@gnu.org'.

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.11.tar.gz   (5.0MB)

Here are the GPG detached signatures[*]:
  ftp://alpha.gnu.org/gnu/guile/guile-1.9.11.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:

ea62d9590f7c7b2552165b44ba11cc3d  guile-1.9.11.tar.gz
abd1424a927302db31395db828d4d14fa68d13f9  guile-1.9.11.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.11.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.65
  Automake 1.11.1
  Libtool 2.2.6b
  Gnulib v0.0-3955-g8ab5996


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 since the 1.9.10 pre-release:

  ** Renamed module: (rnrs bytevectors)

  This module was called (rnrs bytevector), its name from earlier drafts
  of the R6RS. Its name has been changed. Users of previous 1.9 preleases
  may want to search for any stale rnrs/bytevector .go or .scm file, and
  delete them.

  ** New module: (sxml match)

  Guile has incorporated Jim Bender's `sxml-match' library. See
  "sxml-match' in the manual for more information. Thanks, Jim!

  ** New module: (srfi srfi-9 gnu)

  This module adds an extension to srfi-9, `set-record-type-printer!'. See
  "SRFI-9" in the manual for more information.

  ** Support for R6RS libraries

  The `library' and `import' forms from the latest Scheme report have been
  added to Guile, in such a way that R6RS libraries share a namespace with
  Guile modules. R6RS modules may import Guile modules, and are available
  for Guile modules to import via use-modules and all the rest. See "R6RS
  Libraries" in the manual for more information.

  ** Implementations of R6RS libraries

  Guile now has implementations for all of the libraries defined in the
  R6RS. Thanks to Julian Graham for this excellent hack. See "R6RS
  Standard Libraries" in the manual for a full list of libraries.

  ** Partial R6RS compatibility

  Guile now has enough support for R6RS to run a reasonably large subset
  of R6RS programs.

  Guile is not fully R6RS compatible. Many incompatibilities are simply
  bugs, though some parts of Guile will remain R6RS-incompatible for the
  foreseeable future. See "R6RS Incompatibilities" in the manual, for more
  information.

  Please contact bug-guile@gnu.org if you have found an issue not
  mentioned in that compatibility list.

  ** Macro expansion produces structures instead of s-expressions

  In the olden days, macroexpanding an s-expression would yield another
  s-expression. Though the lexical variables were renamed, expansions of
  core forms like `if' and `begin' were still non-hygienic, as they relied
  on the toplevel definitions of `if' et al being the conventional ones.

  The solution is to expand to structures instead of s-expressions. There
  is an `if' structure, a `begin' structure, a `toplevel-ref' structure,
  etc. The expander already did this for compilation, producing Tree-IL
  directly; it has been changed now to do so when expanding for the
  evaluator as well.

  The real truth is somewhat more involved: Tree-IL doesn't exist until
  modules have been booted, but we need the expander to boot modules, and
  additionally we need a boot expander before psyntax is loaded. So a
  subset of Tree-IL is defined in C, and the boot expander produces these
  "macroexpanded" structures. Psyntax has been modified to produce those
  structures as well. When Tree-IL loads, it incorporates those structures
  directly as part of its language.

  Finally, the evaluator has been adapted to accept these "expanded"
  structures, and enhanced to better support the gamut of this subset of
  Tree-IL, including `lambda*' and `case-lambda'. This was a much-needed
  harmonization between the compiler, expander, and evaluator.

  ** Deprecated `scm_badargsp'

  This function is unused in Guile, but was part of its API.

  ** `sxml->xml' enhancement

  `sxml->xml' from `(sxml simple)' can now handle the result of
  `xml->sxml'. See bug #29260 for more information.

  ** New module: (system vm coverage)

  This new module can produce code coverage reports for compiled Scheme
  code on a line-by-line level. See "Code Coverage" in the manual for more
  information.

  ** Faster VM hooks.

  The frame objects passed to VM hook procedures are now allocated on the
  stack instead of the heap, making the next-instruction hook practical to
  use.

  ** New `eval-when' situation: `expand'

  Sometimes it's important to cause side-effects while expanding an
  expression, even in eval mode. This situation is used in
  `define-module', `use-modules', et al, in order to affect the current
  module and its set of syntax expanders.

  ** Better module-level hygiene

  Instead of attempting to track changes to the current module when
  expanding toplevel sequences, we instead preserve referential
  transparency relative to where the macro itself was defined. If the
  macro should expand to expressions in the context of the new module, it
  should wrap those expressions in `@@', which has been enhanced to accept
  generic expressions, not just identifier references. For example, part
  of the definition of the R6RS `library' form:

    #'(begin
        (define-module (name name* ...) #:pure #:version (version ...))
        (import ispec) ...
        (re-export r ...) (export e ...)
        (@@ (name name* ...) body)
        ...)

  In this example the `import' refers to the `import' definition in the
  module where the `library' macro is defined, not in the new module.

  ** Module system macros rewritten as hygienic macros

  `define-module', `use-modules', `export', and other such macros have
  been rewritten as hygienic macros. This allows the necessary referential
  transparency for the R6RS `library' to do the right thing.

  ** Compiler and VM documentation updated

  The documentation for the compiler and VM had slipped out of date; it
  has been brought back... to the future!

  ** Tree-IL field renaming: `vars' -> `gensyms'

  The `vars' fields of <let>, <letrec>, <fix>, and <lambda-case> has been
  renamed to `gensyms', for clarity, and to match <lexical-ref>.

  ** Removed `version' field from <language>

  Language versions weren't being updated or used in any worthwhile way;
  they have been removed, for now at least.

  ** New procedure: `module-export-all!'

  This procedure exports all current and future bindings from a module.
  Use as `(module-export-all! (current-module))'.

  ** Updates to manual

  The introductory sections of the manual have been reorganized
  significantly, making it more accessible to new users of Guile. Check it
  out!

  ** The module namespace is now separate from the value namespace

  It was a little-known implementation detail of Guile's module system
  that it was built on a single hierarchical namespace of values -- that
  if there was a module named `(foo bar)', then there was a also module
  named `(foo)' with a binding from `bar' to the `(foo bar)' module.

  This was a neat trick, but presented a number of problems. One problem
  was that the bindings in a module were not apparent from the module
  itself; perhaps the `(foo)' module had a private binding for `bar', and
  then an external contributor defined `(foo bar)'. In the end there can
  be only one binding, so one of the two will see the wrong thing, and
  produce an obtuse error of unclear provenance.

  Also, the public interface of a module was also bound in the value
  namespace, as `%module-public-interface'. This was a hack from the early
  days of Guile's modules.

  Both of these warts have been fixed by the addition of fields in the
  `module' data type. Access to modules and their interfaces from the
  value namespace has been deprecated, and all accessors use the new
  record accessors appropriately.

  When Guile is built with support for deprecated code, as is the default,
  the value namespace is still searched for modules and public interfaces,
  and a deprecation warning is raised as appropriate.

  Finally, to support lazy loading of modules as one used to be able to do
  with module binder procedures, Guile now has submodule binders, called
  if a given submodule is not found. See boot-9.scm for more information.

  ** New procedures: module-ref-submodule, module-define-submodule,
     nested-ref-module, nested-define-module!, local-ref-module,
     local-define-module

  These new accessors are like their bare variants, but operate on
  namespaces instead of values.

  ** The (app modules) module tree is officially deprecated

  It used to be that one could access a module named `(foo bar)' via
  `(nested-ref the-root-module '(app modules foo bar))'. The `(app
  modules)' bit was a never-used and never-documented abstraction, and has
  been deprecated. See the following mail for a full discussion:

      http://lists.gnu.org/archive/html/guile-devel/2010-04/msg00168.html

  The `%app' binding is also deprecated.

  ** Deprecated `@bind' syntax

  `@bind' was part of an older implementation of the Emacs Lisp language,
  and is no longer used.

  ** New fluid: `%file-port-name-canonicalization'

  This fluid parameterizes the file names that are associated with file
  ports. If %file-port-name-canonicalization is 'absolute, then file names
  are canonicalized to be absolute paths. If it is 'relative, then the
  name is canonicalized, but any prefix corresponding to a member of
  `%load-path' is stripped off. Otherwise the names are passed through
  unchanged.

  ** Source file name canonicalization in `compile-file', `compile-and-load'

  These file-compiling procedures now bind
  %file-port-name-canonicalization to their `#:canonicalization' keyword
  argument, which defaults to 'relative. In this way, one might compile
  "../module/ice-9/boot-9.scm", but the path that gets residualized into
  the .go is "ice-9/boot-9.scm".

  ** Deprecate arity access via (procedure-properties proc 'arity)

  Instead of accessing a procedure's arity as a property, use the new
  `procedure-minimum-arity' function, which gives the most permissive
  arity that the the function has, in the same format as the old arity
  accessor.

  ** Remove redundant accessors: program-name, program-documentation,
     program-properties, program-property

  Instead, just use procedure-name, procedure-documentation,
  procedure-properties, and procedure-property.

  ** Enhance documentation for support of Emacs Lisp's `nil'

  See "Nil" in the manual, for more details.

  ** Enhance documentation for support of other languages

  See "Other Languages" in the manual, for more details.

  ** 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 `bug-guile@gnu.org'.  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.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: GNU Guile 1.9.11 released (beta)

[Taylor Venable]

On Tue, Jun 1, 2010 at 5:57 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> We are pleased to announce GNU Guile release 1.9.11.  This may be the
> last pre-release before the 2.0 release.

During the configure process, the script produces errors in the shell:

./configure: line 20215: test: -lt: unary operator expected
./configure: line 20216: test: -eq: unary operator expected
./configure: line 20252: test: -lt: unary operator expected
./configure: line 20253: test: -eq: unary operator expected
./configure: line 20306: test: -lt: unary operator expected
./configure: line 20307: test: -eq: unary operator expected
./configure: line 20360: test: -lt: unary operator expected
./configure: line 20361: test: -eq: unary operator expected
./configure: line 20397: test: -lt: unary operator expected
./configure: line 20398: test: -eq: unary operator expected
./configure: line 20441: test: -lt: unary operator expected
./configure: line 20442: test: -eq: unary operator expected
./configure: line 20488: test: -lt: unary operator expected
./configure: line 20489: test: -eq: unary operator expected

This comes from the libunistring tests.  I do not get this when
configuring the 1.9.10 tarball.  [I tried sending this with my
config.log attached but the message bounced so I've placed it on my
website: http://metasyntax.net/guile-config.log - this message is
being resent to the mailing list addresses which bounced it]  I'm not
sure if anything in the build is affected; the configure process does
finish successfully.  I'll be happy to provide any more information or
investigation if it will help.

-- 
Taylor C. Venable
http://metasyntax.net/

Re: GNU Guile 1.9.11 released (beta)

[Taylor Venable]

On Fri, Jun 11, 2010 at 6:23 PM, Taylor Venable <taylor@metasyntax.net> wrote:
> On Tue, Jun 1, 2010 at 5:57 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> We are pleased to announce GNU Guile release 1.9.11.  This may be the
>> last pre-release before the 2.0 release.
>
> During the configure process, the script produces errors in the shell:
>
> ./configure: line 20215: test: -lt: unary operator expected
> ./configure: line 20216: test: -eq: unary operator expected
> ./configure: line 20252: test: -lt: unary operator expected
> ./configure: line 20253: test: -eq: unary operator expected
> ./configure: line 20306: test: -lt: unary operator expected
> ./configure: line 20307: test: -eq: unary operator expected
> ./configure: line 20360: test: -lt: unary operator expected
> ./configure: line 20361: test: -eq: unary operator expected
> ./configure: line 20397: test: -lt: unary operator expected
> ./configure: line 20398: test: -eq: unary operator expected
> ./configure: line 20441: test: -lt: unary operator expected
> ./configure: line 20442: test: -eq: unary operator expected
> ./configure: line 20488: test: -lt: unary operator expected
> ./configure: line 20489: test: -eq: unary operator expected

I did a little more research on this today; it happens with the three
most recent versions of libunistring (0.9.2 ; 0.9.2.1 ; 0.9.3), and
the reason it doesn't occur in Guile 1.9.10 is because the configure
script there doesn't use the gnulib libunistring modules (where the
errors appear) to check the installed libunistring version
(specifically, from file m4/libunistring-base.m4[1]).

With some deeper probing (quite ... enlightening ... work - I've never
really examined how configure scripts are written before) I think I've
identified the origin of the problem.  On line 12165, if
HAVE_LIBUNISTRING is yes then the version number is extracted into
major/minor/subminor components.  However, HAVE_LIBUNISTRING isn't set
to yes or no until at the earliest line 15115, and the version itself
isn't extracted from the header file until line 16197 I think, so the
version components are always unset.  The version checking code
assumes that if HAVE_LIBUNISTRING is yes then the version components
have been extracted, but with the ordering in the configure file this
seems impossible: the version components will always be unset and
HAVE_LIBUNISTRING may be either yes or no.  It seems that a fix for
this problem is to move that version extraction code (starting at
12165) down in the file so that it appears after LIBUNISTRING_VERSION
has been set (for example, down near line 16280).  Doing this in the
configure script itself causes success, but I don't really know how
that script is generated, so hopefully this is enough information to
help the developers get the "right" solution.

[1] http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/libunistring-base.m4

Best regards,

-- 
Taylor C. Venable
http://metasyntax.net/

Re: GNU Guile 1.9.11 released (beta)

[Ludovic Courtès]

Hi,

Taylor Venable <taylor@metasyntax.net> writes:

> During the configure process, the script produces errors in the shell:
>
> ./configure: line 20215: test: -lt: unary operator expected
> ./configure: line 20216: test: -eq: unary operator expected
> ./configure: line 20252: test: -lt: unary operator expected
> ./configure: line 20253: test: -eq: unary operator expected
> ./configure: line 20306: test: -lt: unary operator expected
> ./configure: line 20307: test: -eq: unary operator expected
> ./configure: line 20360: test: -lt: unary operator expected
> ./configure: line 20361: test: -eq: unary operator expected
> ./configure: line 20397: test: -lt: unary operator expected
> ./configure: line 20398: test: -eq: unary operator expected
> ./configure: line 20441: test: -lt: unary operator expected
> ./configure: line 20442: test: -eq: unary operator expected
> ./configure: line 20488: test: -lt: unary operator expected
> ./configure: line 20489: test: -eq: unary operator expected

This is a known (and harmless) problem, now fixed in Gnulib.  See
<http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00226.html> and
<http://lists.gnu.org/archive/html/bug-gnulib/2010-06/msg00001.html>.

Thanks,
Ludo’.