guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Guile 1.9.6 released (alpha)


From: Ludovic Courtès
Subject: GNU Guile 1.9.6 released (alpha)
Date: Wed, 16 Dec 2009 00:24:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

We are pleased to announce GNU Guile release 1.9.6.  This is the next
pre-release of what will eventually become the 2.0 release series.  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,
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.6.tar.gz   (4.6MB)

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

4b124824a7f4d8a79f14d9c9297d6cfa  guile-1.9.6.tar.gz
365341f996ea28bac08a7f38268ef3279fdedaaf  guile-1.9.6.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.6.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-3026-g3fd9a2d


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.5 pre-release:

  ** New implementation of `primitive-eval'

  Guile's `primitive-eval' is now implemented in Scheme. Actually there is
  still a C evaluator, used when building a fresh Guile to interpret the
  compiler, so we can compile eval.scm. Thereafter all calls to
  primitive-eval are implemented by VM-compiled code.

  This allows all of Guile's procedures, be they interpreted or compiled,
  to execute on the same stack, unifying multiple-value return semantics,
  providing for proper tail recursion between interpreted and compiled
  code, and simplifying debugging.

  As part of this change, the evaluator no longer mutates the internal
  representation of the code being evaluated in a thread-unsafe manner.

  There are two negative aspects of this change, however. First, Guile
  takes a lot longer to compile now. Also, there is less debugging
  information available for debugging interpreted code. We hope to improve
  both of these situations.

  There are many changes to the internal C evalator interface, but all
  public interfaces should be the same. See the ChangeLog for details. If
  we have inadvertantly changed an interface that you were using, please
  contact address@hidden

  ** Elisp compiler

  The derelict Guile maintainers finally got around to merging Daniel
  Kraft's excellent Emacs Lisp compiler. You can now switch to Elisp at
  the repl: `,language elisp'. All kudos to Daniel, and all bugs to
  address@hidden

  ** Faster SRFI-9 record access

  SRFI-9 records are now implemented directly on top of Guile's structs,
  and their accessors are defined in such a way that normal call-sites
  inline to special VM opcodes, while still allowing for the general case
  (e.g. passing a record accessor to `apply').

  ** Some VM metadata removed

  It used to be that the standard virtual machine counted the number of
  instructions it executed. This capability has been removed, as it was
  not very useful, and had some overhead. Also it used to try to record
  the time spent in the VM, but these calculations were borked, so we
  removed them too.

  ** Inline memq/memv of a key in a constant list

  The impoverished Guile inliner is slightly less lame now that it does
  `(memv k '(foo))' => `(eq? k 'foo)'. 

  ** Rename "else" fields of <conditional> and <lambda-case>

  Having a field named "else" just didn't sit right with "cond", and
  everything else. So now Tree-IL's <conditional> has "consequent" and
  "alternate", and <lambda-case> has "alternate".

  ** Allow interrupts in tail loops

  Tail-recursive loops that compile to tight, procedure-less jumps
  previously were uninterruptible. Now the VM handle interrupts whenever
  it jumps backwards.

  ** Tail patterns in syntax-case

  Guile has pulled in some more recent changes from the psyntax portable
  syntax expander, to implement support for "tail patterns". Such patterns
  are supported by syntax-rules and syntax-case. This allows a syntax-case
  match clause to have ellipses, then a pattern at the end. For example:

    (define-syntax case
      (syntax-rules (else)
        ((_ val match-clause ... (else e e* ...))
         [...])))

  Note how there is MATCH-CLAUSE, which is ellipsized, then there is a
  tail pattern for the else clause. Thanks to Andreas Rottmann for the
  patch, and Kent Dybvig for the code.

  ** New struct constructors that don't involve making lists

  `scm_c_make_struct' and `scm_c_make_structv' are new varargs and array
  constructors, respectively, for structs. You might find them useful.

  ** Applicable struct support

  One may now make structs from Scheme that may be applied as procedures.
  To do so, make a struct whose vtable is `<applicable-struct-vtable>'.
  That struct will be the vtable of your applicable structs; instances of
  that new struct are assumed to have the procedure in their first slot.
  `<applicable-struct-vtable>' is like Common Lisp's
  `funcallable-standard-class'. Likewise there is
  `<applicable-struct-with-setter-vtable>', which looks for the setter in
  the second slot. This needs to be better documented.

  ** GOOPS dispatch in scheme

  As an implementation detail, GOOPS dispatch is no longer implemented by
  special evaluator bytecodes, but rather directly via a Scheme function
  associated with an applicable struct. There is some VM support for the
  underlying primitives, like `class-of'.

  This change will in the future allow users to customize generic function
  dispatch without incurring a performance penalty, and allow us to
  implement method combinations.

  ** Procedures-with-setters are now implemented using applicable structs

  From a user's perspective this doesn't mean very much. But if, for some
  odd reason, you used the SCM_PROCEDURE_WITH_SETTER_P, SCM_PROCEDURE, or
  SCM_SETTER macros, know that they're deprecated now. Also, scm_tc7_pws
  is gone.

  ** No more `local-eval'

  `local-eval' used to exist so that one could evaluate code in the
  lexical context of a function. Since there is no way to get the lexical
  environment any more, as that concept has no meaning for the compiler,
  and a different meaning for the interpreter, we have removed the
  function.

  If you think you need `local-eval', you should probably implement your
  own metacircular evaluator. It will probably be as fast as Guile's
  anyway.

  ** Bit twiddlings

  *** Remove old evaluator closures

  There used to be ranges of typecodes allocated to interpreted data
  structures, but that it no longer the case, given that interpreted
  procedure are now just regular VM closures. As a result, there is a
  newly free tc3, and a number of removed macros. See the ChangeLog for
  details.

  *** Simplify representation of primitive procedures

  It used to be that there were something like 12 different typecodes
  allocated to primitive procedures, each with its own calling convention.
  Now there is only one, the gsubr. This may affect user code if you were
  defining a procedure using scm_c_make_subr rather scm_c_make_gsubr. The
  solution is to switch to use scm_c_make_gsubr. This solution works well
  both with the old 1.8 and and with the current 1.9 branch.

  *** Some SMOB types changed to have static typecodes

  Fluids, dynamic states, and hash tables used to be SMOB objects, but now
  they have statically allocated tc7 typecodes.

  *** Preparations for changing SMOB representation

  If things go right, we'll be changing the SMOB representation soon. To
  that end, we did a lot of cleanups to calls to e.g. SCM_CELL_WORD_2(x) when
  the code meant SCM_SMOB_DATA_2(x); user code will need similar changes
  in the future. Code accessing SMOBs using SCM_CELL macros was never
  correct, but until now things still worked. Users should be aware of
  such changes.

  ** Stack refactor

  It used to be that Guile had debugging frames on the C stack and on the
  VM stack. Now Guile's procedures only run on the VM stack, simplifying
  much of the C API. See the ChangeLog for details. The Scheme API has not
  been changed significantly.

  ** New procedure, `define!'

  `define!' is a procedure that takes two arguments, a symbol and a value,
  and binds the value to the symbol in the current module. It's useful to
  programmatically make definitions in the current module, and is slightly
  less verbose than `module-define!'.

  ** eqv? not a generic

  One used to be able to extend `eqv?' as a primitive-generic, but no
  more. Because `eqv?' is in the expansion of `case' (via `memv'), which
  should be able to compile to static dispatch tables, it doesn't make
  sense to allow extensions that would subvert this optimization.

  ** Deprecate trampolines

  There used to be C functions `scm_trampoline_0', `scm_trampoline_1', and
  so on. The point was to do some precomputation on the type of the
  procedure, then return a specialized "call" procedure. However this
  optimization wasn't actually an optimization, so it is now deprecated.
  Just use `scm_call_0', etc instead.

  ** Undeprecate `scm_the_root_module ()'

  It's useful to be able to get the root module from C without doing a
  full module lookup.

  ** New struct slot allocation: "hidden"

  A hidden slot is readable and writable, but will not be initialized by a
  call to make-struct. For example in your layout you would say "ph"
  instead of "pw". Hidden slots are useful for adding new slots to a
  vtable without breaking existing invocations to make-struct.

  ** New type definitions for `scm_t_intptr' and friends.

  `SCM_T_UINTPTR_MAX', `SCM_T_INTPTR_MIN', `SCM_T_INTPTR_MAX',
  `SIZEOF_SCM_T_BITS', `scm_t_intptr' and `scm_t_uintptr' are now
  available to C. Have fun!

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

Attachment: pgptBpUar6J8n.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]