@c -*-texinfo-*-
@c This is part of the GNU Guile Reference Manual.
-@c Copyright (C) 2008
+@c Copyright (C) 2008, 2010, 2011, 2013
@c Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.
Due to a naming conflict with another programming language, Jim Blandy
suggested a new name for GEL: ``Guile''. Besides being a recursive
-acroymn, ``Guile'' craftily follows the naming of its ancestors,
+acronym, ``Guile'' craftily follows the naming of its ancestors,
``Planner'', ``Conniver'', and ``Schemer''. (The latter was truncated
to ``Scheme'' due to a 6-character file name limit on an old operating
system.) Finally, ``Guile'' suggests ``guy-ell'', or ``Guy L.
with us today.
@node A Scheme of Many Maintainers
-@subsection A Scheme of Many Mantainers
+@subsection A Scheme of Many Maintainers
Surveying the field, it seems that Scheme implementations correspond
with their maintainers on an N-to-1 relationship. That is to say, that
Guile is atypical in this regard.
-Tom Lord maintaned Guile for its first year and a half or so,
+Tom Lord maintained Guile for its first year and a half or so,
corresponding to the end of 1994 through the middle of 1996. The
releases made in this time constitute an arc from SCM as a standalone
program to Guile as a reusable, embeddable library, but passing
Only some of those features remain in Guile. There were ongoing
tensions between providing a small, embeddable language, and one which
-had all of the features (e.g. a graphical toolkit) that a modern Emacs
+had all of the features (e.g.@: a graphical toolkit) that a modern Emacs
might need. In the end, as Guile gained in uptake, the development
team decided to focus on depth, documentation and orthogonality rather
than on breadth. This has been the focus of Guile ever since, although
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 Courtès stepped up to take on
-the primary maintenance responsibility.
+other things, so Neil Jerram and Ludovic Court@`es
+stepped up to take on the primary maintenance responsibility. Jerram and
+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
@itemx 1.2 --- 24 June 1997
Support for Tcl/Tk and ctax were split off as separate packages, and
have remained there since. Guile became more compatible with SCSH, and
-more useful as a UNIX scripting language. Libguile can now be built as
+more useful as a UNIX scripting language. Libguile could now be built as
a shared library, and third-party extensions written in C became
loadable via dynamic linking.
@item 1.3.0 --- 19 October 1998
Command-line editing became much more pleasant through the use of the
readline library. The initial support for internationalization via
-multi-byte strings was removed, and has yet to be added back, though
-UTF-8 hacks are common. Modules gained the ability to have custom
-expanders, which is still used for syntax-case macros. Initial Emacs
-Lisp support landed, ports gained better support for file descriptors,
-and fluids were added.
+multi-byte strings was removed; 10 years were to pass before proper
+internationalization would land again. Initial Emacs Lisp support
+landed, ports gained better support for file descriptors, and fluids
+were added.
@item 1.3.2 --- 20 August 1999
@itemx 1.3.4 --- 25 September 1999
A long list of lispy features were added: hooks, Common Lisp's
@code{format}, optional and keyword procedure arguments,
@code{getopt-long}, sorting, random numbers, and many other fixes and
-enhancements. Guile now has an interactive debugger, interactive help,
-and gives better backtraces.
+enhancements. Guile also gained an interactive debugger, interactive
+help, and better backtraces.
@item 1.6 --- 6 September 2002
Guile gained support for the R5RS standard, and added a number of SRFI
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 --- thus far, only unstable snapshots available
-A virtual machine was added to Guile, along with the associated
-compiler and toolchain. Support for internationalization was added.
-Running Guile instances became controllable and debuggable from within
-Emacs, via GDS, which was also backported to 1.8.5. An SRFI-18
-interface to multithreading was added, including thread cancellation.
+@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 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
language with a syntax that is closer to C, or to Python. Another
-interesting idea to consider is compiling e.g. Python to Guile. It's
+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 translator 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