@c -*-texinfo-*-
@c This is part of the GNU Guile Reference Manual.
-@c Copyright (C) 2008, 2010
+@c Copyright (C) 2008, 2010, 2011, 2013
@c Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.
Since then, Guile has had a group maintainership. The first group was
Maciej Stachowiak, Mikael Djurfeldt, and Marius Vollmer, with Vollmer
staying on the longest. By late 2007, Vollmer had mostly moved on to
-other things, so Neil Jerram and Ludovic
-@iftex
-Court@`es
-@end iftex
-@ifnottex
-Courtès
-@end ifnottex
+other things, so Neil Jerram and Ludovic Court@`es
stepped up to take on the primary maintenance responsibility. Jerram and
-@iftex
-Court@`es
-@end iftex
-@ifnottex
-Courtès
-@end ifnottex
-were joined by Andy Wingo in late 2009.
+Court@`es were joined by Andy Wingo in late 2009.
Of course, a large part of the actual work on Guile has come from
other contributors too numerous to mention, but without whom the world
threads, providing true multiprocessing. Gettext support was added,
and Guile's C API was cleaned up and orthogonalized in a massive way.
-@item 2.0 --- April 2010
+@item 2.0 --- 16 February 2010
A virtual machine was added to Guile, along with the associated compiler
and toolchain. Support for internationalization was finally
reimplemented, in terms of unicode, locales, and libunistring. Running
Guile instances became controllable and debuggable from within Emacs,
-via GDS and Geiser. Guile caught up to features found in a number of
-other Schemes: SRFI-18 threads, including thread cancellation,
-module-hygienic macros, a profiler, tracer, and debugger, SSAX XML
-integration, bytevectors, module versions, and partial support for R6RS.
+via Geiser. Guile caught up to features found in a number of other
+Schemes: SRFI-18 threads, module-hygienic macros, a profiler, tracer,
+and debugger, SSAX XML integration, bytevectors, a dynamic FFI,
+delimited continuations, module versions, and partial support for R6RS.
+
+@item 2.2 --- mid-2014
+The virtual machine and introduced in 2.0 was completely rewritten,
+along with much of the compiler and toolchain. This speeds up many
+Guile programs as well as reducing startup time and memory usage. A PEG
+parser toolkit was added, making it easier to write other language
+frontends.
@end table
@node Status
These days it is possible to write extensible applications almost
entirely from high-level languages, through byte-code and native
compilation, speed gains in the underlying hardware, and foreign call
-interfaces in the high-level language. Smalltalk systems are like
-this, as are Common Lisp-based systems. While there already are a
-number of pure-Guile applications out there, users still need to drop
-down to C for some tasks: interfacing to system libraries that don't
-have prebuilt Guile interfaces, and for some tasks requiring high
-performance.
-
-The addition of the virtual machine in Guile 2.0, together with the
-compiler infrastructure, should go a long way to addressing the speed
-issues. But there is much optimization to be done. Interested
-contributors will find lots of delightful low-hanging fruit, from
-simple profile-driven optimization to hacking a just-in-time compiler
-from VM bytecode to native code.
+interfaces in the high-level language. Smalltalk systems are like this,
+as are Common Lisp-based systems. While there already are a number of
+pure-Guile applications out there, users still need to drop down to C
+for some tasks: interfacing to system libraries that don't have prebuilt
+Guile interfaces, and for some tasks requiring high performance. Native
+ahead-of-time compilation, planned for Guile 3.0, should help with
+this.
Still, even with an all-Guile application, sometimes you want to
provide an opportunity for users to extend your program from a
interesting idea to consider is compiling e.g.@: Python to Guile. It's
not that far-fetched of an idea: see for example IronPython or JRuby.
-And then there's Emacs itself. Though there is a somewhat-working Emacs
-Lisp language frontend for Guile, it cannot yet execute all of Emacs
-Lisp. A serious integration of Guile with Emacs would replace the Elisp
-virtual machine with Guile, and provide the necessary C shims so that
-Guile could emulate Emacs' C API. This would give lots of exciting
-things to Emacs: native threads, a real object system, more
-sophisticated types, cleaner syntax, and access to all of the Guile
-extensions.
+And then there's Emacs itself. Guile's Emacs Lisp support has reached
+an excellent level of correctness, robustness, and speed. However there
+is still work to do to finish its integration into Emacs itself. This
+will give lots of exciting things to Emacs: native threads, a real
+object system, more sophisticated types, cleaner syntax, and access to
+all of the Guile extensions.
Finally, there is another axis of crystallization, the axis between
-different Scheme implementations. Guile does not yet support the
-latest Scheme standard, R6RS, and should do so. Like all standards,
-R6RS is imperfect, but supporting it will allow more code to run on
-Guile without modification, and will allow Guile hackers to produce
-code compatible with other schemes. Help in this regard would be much
+different Scheme implementations. Guile does not yet support the latest
+Scheme standard, R7RS, and should do so. Like all standards, R7RS is
+imperfect, but supporting it will allow more code to run on Guile
+without modification, and will allow Guile hackers to produce code
+compatible with other schemes. Help in this regard would be much
appreciated.
HCoop / bpt / guile.git / blobdiff