diff options
Diffstat (limited to 'doc/ref/history.texi')
-rw-r--r-- | doc/ref/history.texi | 293 |
1 files changed, 293 insertions, 0 deletions
diff --git a/doc/ref/history.texi b/doc/ref/history.texi new file mode 100644 index 000000000..d23d5a08d --- /dev/null +++ b/doc/ref/history.texi @@ -0,0 +1,293 @@ +@c -*-texinfo-*- +@c This is part of the GNU Guile Reference Manual. +@c Copyright (C) 2008, 2010, 2011, 2013, 2018 +@c Free Software Foundation, Inc. +@c See the file guile.texi for copying conditions. + +@node History +@section A Brief History of Guile + +Guile is an artifact of historical processes, both as code and as a +community of hackers. It is sometimes useful to know this history when +hacking the source code, to know about past decisions and future +directions. + +Of course, the real history of Guile is written by the hackers hacking +and not the writers writing, so we round up the section with a note on +current status and future directions. + +@menu +* The Emacs Thesis:: +* Early Days:: +* A Scheme of Many Maintainers:: +* A Timeline of Selected Guile Releases:: +* Status:: +@end menu + +@node The Emacs Thesis +@subsection The Emacs Thesis + +The story of Guile is the story of bringing the development experience +of Emacs to the mass of programs on a GNU system. + +Emacs, when it was first created in its GNU form in 1984, was a new +take on the problem of ``how to make a program''. The Emacs thesis is +that it is delightful to create composite programs based on an +orthogonal kernel written in a low-level language together with a +powerful, high-level extension language. + +Extension languages foster extensible programs, programs which adapt +readily to different users and to changing times. Proof of this can be +seen in Emacs' current and continued existence, spanning more than a +quarter-century. + +Besides providing for modification of a program by others, extension +languages are good for @emph{intension} as well. Programs built in +``the Emacs way'' are pleasurable and easy for their authors to flesh +out with the features that they need. + +After the Emacs experience was appreciated more widely, a number of +hackers started to consider how to spread this experience to the rest +of the GNU system. It was clear that the easiest way to Emacsify a +program would be to embed a shared language implementation into it. + +@node Early Days +@subsection Early Days + +Tom Lord was the first to fully concentrate his efforts on an +embeddable language runtime, which he named ``GEL'', the GNU Extension +Language. + +GEL was the product of converting SCM, Aubrey Jaffer's implementation +of Scheme, into something more appropriate to embedding as a library. +(SCM was itself based on an implementation by George Carrette, SIOD.) + +Lord managed to convince Richard Stallman to dub GEL the official +extension language for the GNU project. It was a natural fit, given +that Scheme was a cleaner, more modern Lisp than Emacs Lisp. Part of +the argument was that eventually when GEL became more capable, it +could gain the ability to execute other languages, especially Emacs +Lisp. + +Due to a naming conflict with another programming language, Jim Blandy +suggested a new name for GEL: ``Guile''. Besides being a recursive +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. +Steele'', who, together with Gerald Sussman, originally discovered +Scheme. + +Around the same time that Guile (then GEL) was readying itself for +public release, another extension language was gaining in popularity, +Tcl. Many developers found advantages in Tcl because of its shell-like +syntax and its well-developed graphical widgets library, Tk. Also, at +the time there was a large marketing push promoting Tcl as a +``universal extension language''. + +Richard Stallman, as the primary author of GNU Emacs, had a particular +vision of what extension languages should be, and Tcl did not seem to +him to be as capable as Emacs Lisp. He posted a criticism to the +comp.lang.tcl newsgroup, sparking one of the internet's legendary +flamewars. As part of these discussions, retrospectively dubbed the +``Tcl Wars'', he announced the Free Software Foundation's intent to +promote Guile as the extension language for the GNU project. + +It is a common misconception that Guile was created as a reaction to +Tcl. While it is true that the public announcement of Guile happened +at the same time as the ``Tcl wars'', Guile was created out of a +condition that existed outside the polemic. Indeed, the need for a +powerful language to bridge the gap between extension of existing +applications and a more fully dynamic programming environment is still +with us today. + +@node A Scheme of Many Maintainers +@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 +those people that implement Schemes might do so on a number of +occasions, but that the lifetime of a given Scheme is tied to the +maintainership of one individual. + +Guile is atypical in this regard. + +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 +through a explosion of features: embedded Tcl and Tk, a toolchain for +compiling and disassembling Java, addition of a C-like syntax, +creation of a module system, and a start at a rich POSIX interface. + +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 +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 +there is a wide range of third-party libraries for Guile. + +Jim Blandy presided over that period of stabilization, in the three +years until the end of 1999, when he too moved on to other projects. +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@`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 +would be a poorer place. + +@node A Timeline of Selected Guile Releases +@subsection A Timeline of Selected Guile Releases + +@table @asis +@item guile-i --- 4 February 1995 +SCM, turned into a library. + +@item guile-ii --- 6 April 1995 +A low-level module system was added. Tcl/Tk support was added, +allowing extension of Scheme by Tcl or vice versa. POSIX support was +improved, and there was an experimental stab at Java integration. + +@item guile-iii --- 18 August 1995 +The C-like syntax, ctax, was improved, but mostly this release +featured a start at the task of breaking Guile into pieces. + +@item 1.0 --- 5 January 1997 +@code{#f} was distinguished from @code{'()}. User-level, cooperative +multi-threading was added. Source-level debugging became more useful, +and programmer's and user's manuals were begun. The module system +gained a high-level interface, which is still used today in more or +less the same form. + +@item 1.1 --- 16 May 1997 +@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 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; 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 +@itemx 1.4 --- 21 June 2000 +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 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 +modules. The module system was expanded with programmatic support for +identifier selection and renaming. The GOOPS object system was merged +into Guile core. + +@item 1.8 --- 20 February 2006 +Guile's arbitrary-precision arithmetic switched to use the GMP +library, and added support for exact rationals. Guile's embedded +user-space threading was removed in favor of POSIX pre-emptive +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 --- 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 --- 15 March 2017 +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. +Guile's POSIX multithreading was improved, stacks became dynamically +expandable, the ports facility gained support for non-blocking I/O. + +@item 3.0 -- early 2019 (unreleased at time of writing) +Guile gained support for native code generation via a simple +just-in-time (JIT) compiler, further improving the speed of its virtual +machine. +@end table + +@node Status +@subsection Status, or: Your Help Needed + +Guile has achieved much of what it set out to achieve, but there is +much remaining to do. + +There is still the old problem of bringing existing applications into +a more Emacs-like experience. Guile has had some successes in this +respect, but still most applications in the GNU system are without +Guile integration. + +Getting Guile to those applications takes an investment, the +``hacktivation energy'' needed to wire Guile into a program that only +pays off once it is good enough to enable new kinds of behavior. This +would be a great way for new hackers to contribute: take an +application that you use and that you know well, think of something +that it can't yet do, and figure out a way to integrate Guile and +implement that task in Guile. + +With time, perhaps this exposure can reverse itself, whereby programs +can run under Guile instead of vice versa, eventually resulting in the +Emacsification of the entire GNU system. Indeed, this is the reason +for the naming of the many Guile modules that live in the @code{ice-9} +namespace, a nod to the fictional substance in Kurt Vonnegut's +novel, Cat's Cradle, capable of acting as a seed crystal to +crystallize the mass of software. + +Implicit to this whole discussion is the idea that dynamic languages +are somehow better than languages like C. While languages like C have +their place, Guile's take on this question is that yes, Scheme is more +expressive than C, and more fun to write. This realization carries an +imperative with it to write as much code in Scheme as possible rather +than in other languages. + +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, in the past users have still needed +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. With the arrival of native code generation via a JIT +compiler in Guile 3.0, most of these older applications can now be +updated to move more C code to Scheme. + +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 +not that far-fetched of an idea: see for example IronPython or JRuby. + +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, 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. |