* policy/goals.text, policy/principles.text, policy/plans.text:

New files.

devel/policy/goals.text

@@ -0,0 +1,82 @@
+This file states the goals of Guile.
+
+* Goals of Guile
+
+Guile is many things to many people.  It has multiple ways to approach
+it: as a C library that provides an extension language, as a
+programming language in its own right, as a interface to the operating
+system, as an interactive shell, or as a platform that integrates many
+independent subsystems.
+
+These different roles have a lot in common, but there are also some
+opposing forces that need to be balanced.
+
+Not everything of what is outlined below has been realized yet.  The
+things that are missing will receive high priority from the
+maintainers of Guile.  One thing that is not mentioned below because
+it goes without saying is documentation.  It is of course a goal of
+Guile to have high quality documentation.
+
+More information about the current status of Guile and planned changed
+can be found in the file "plans.text".
+
+** Guile as an extension language library
+
+Guile's primary aim is to provide a good extension language which is
+easy to add to an application written in C on a UNIX machine.  This
+means that it must export the features of a higher level language in a
+way that makes it easy not to break them from C code.
+
+For example, one important feature of Guile is automatic garbage
+collection.  The C interface to the garbage collector makes it easy to
+use its services for the data structures of the application itself.
+
+** Guile as a programming language
+
+It is an aim to support easy programming using Guile.  This includes
+providing the powerful features of the programming language Scheme,
+like garbage collection, dynamic types, hygienic macros and higher
+order functions.
+
+This also includes things that go beyond standard Scheme, like a
+module system to manage multiple name spaces, a system for object
+oriented programming, support for comfortable multi-threading, and
+internationalization features like Unicode support.
+
+To make it useful, Guile offers good performance.
+
+** Guile as an interface to the operating system
+
+Guile supports most of the POSIX system calls.  Most of Scsh is
+available to Guile users and Guile programs.  Beyond POSIX, Guile also
+makes available important system libraries like the graphical toolkit
+Gtk+.
+
+** Guile as an interactive shell
+
+Guile provides a command line interface with readline support.  The
+interactive features of the programming language allow you to
+incrementally alter a running system.  A integrated debugger allows
+you to analyze such a running system in great detail.
+
+Guile provides online documentation for most of its features.
+
+Guile can also be controlled from Emacs.  This allows you to update
+the definition of a function or some other object in a Guile process
+with the touch of a few keys.  You have access to the documentation in
+a context sensitive way.  It also integrates the debugger nicely into
+your editing environment.
+
+** Guile as an integration platform
+
+With all the features describes above, Guile allows the implementation
+of well behaved modules.  When most of an application is implemented
+as modules with generality and re-usability in mind, Guile will be the
+platform where the integration and reusing will take place.
+
+Thus, Guile makes it easy to factor your application into well
+separated modules and then finish it off by combining them with a thin
+layer of Scheme code.
+
+Guile has support for writing modules in C or other compiled
+languages.

devel/policy/plans.text

@@ -0,0 +1,278 @@
+This file describes the current status and future plans for Guile development.
+
+* Status
+
+To give you an idea how far we are from the things described above,
+here is the status of some topics.  Guile used to suck, but it doesn't
+any more.
+
+** Documentation
+
+XXX - Losta stuff, and talk also about updating the web page.
+
+** Object oriented programming
+
+Guile's object system is GOOPS.  XXX - Some notes about
+characteristics and motivations.
+
+** Multithreading
+
+At the moment, Guile supports co-operative threading on several
+platforms.  We do *not* support true kernel threads at present, not
+because we don't think that would be way cool, but because it's
+really, really hard.  We're taking continually taking steps towards
+that goal, however.
+
+Current status is that necessary basic changes to the garbage
+collector and the signal handling has been done.  (Few are aware of
+it, but the SCM_DEFER_INTS/SCM_ALLOW_INTS macros no longer have any
+effect!)
+
+The major remaining work is to protect common resources using mutecis.
+
+*** Using Guile's COOP threads in a POSIX threaded application
+
+A recent change has made it possible to mix use of Guile's COOP
+threads and POSIX threads in a single application.  This is useful,
+since some GNOME libraries links with pthreads by default.  (Guile
+still has to run in a single POSIX thread, and the two thread systems
+needs to use independent sets of thread synchronization mechanisms,
+however.)
+
+** Graphical toolkit
+
+You can access Gtk+ from Guile by using the (separate) guile-gtk
+package.  The basic machinery of guile-gtk is mostly done but
+individual features of Gtk+ are missing.  Adding these features is
+mostly the job of taking a look whether they are safe to export in
+unmodified form and when that is the case, writing a couple of easy
+lines of descriptions for the feature.  This is mostly busy work.
+
+XXX - guile-tcltk?
+
+* Near Future
+
+What is planned for the near future.
+
+** Breakpoints and single-stepping in the debugger
+
+Guile now has a debugger (try `(debug)').  We are planning to
+implement breakpoints and single-stepping, and then announce the
+debugger in README file and documentation.
+
+** A new module system
+
+Integration of Jost Boekemeiers environment implementation.  Greg
+Badros has promised to try to integrate them.
+
+On top of that, a new module system will be implemented, but:
+ 1) We're not settled yet,
+ 2) we're really trying to settle it, and
+ 3) we're discovering why the rest of the Scheme scene isn't 
+    settled on this issue either.
+
+There will be a C API to the new module system.
+
+** Factorization of Guile into function libraries
+
+Although Guile is meant to support composing a system from modules
+well, it does not make use of this principle itself.  The core is
+quite monolithic and includes a lot of things that could be separated
+out.
+
+We will be moving such things as networking, posix and regular
+expression support to separate modules instead of having them all in
+the root namespace.
+
+** Faster startup
+
+We will make Guile start up quicker.  Guile's current slow startup is
+primarily due to 1. inefficient code in a time-critical place in the
+current module system, and, 2. that too much code is loaded at
+startup.
+
+** Translators
+
+XXX - ???
+
+*** C-like syntax for Scheme
+*** elisp
+*** tcl
+*** python
+
+* The Guile wishlist
+
+** Revision and stabilization of interfaces
+
+Along with the updating the documentation, we should clean up the
+interfaces of Guile.  
+
+It should be well defined which existing Scheme procedures and C
+functions and macros are supported as part of the "Guile language" and
+which are temporary procedures used in the implementation of Guile or
+historical remnants.
+
+** Full R5RS compliance
+
+XXX 
+
+** SRFIs
+
+XXX
+
+** Reorganization of the numeric code
+
+Numeric tower
+
+3. Introduce a subclass of <generic> called <arithmetic-generic>.
+
+   Such objects contain 7 pointers to C functions handling the argument
+   combinations (), (INUM), (REAL), (INUM, INUM), (REAL, INUM),
+   (INUM, REAL) and (REAL, REAL).
+
+   When an <arithmetic-generic> is applied, it first uses simple
+   if-statements to dispatch onto one of these "primitive methods".
+   If that fails, it behaves as an ordinary generic, i.e., it does
+   type dispatch.
+
+4. Turn all standard Guile arithmetic, and comparison operators into
+   <arithmetic-generic>s and break up numbers.c into independent
+   modules.
+
+After this, we can easily add new types to the numeric tower.  The new
+types will be handled a little bit slower than INUMs and REALs, but I
+think it will be fast enough.
+
+Some fundamental changes have already been done that make floating
+point calculations more efficient.
+
+** Low-level support for hygienic macros
+
+Instead of a well integrated support for hygieneic macros, Guile
+provides three redundant ways of defining unhygienic macros:
+`procedure->macro', `defmacro' (with `defmacro-public'), and,
+`define-macro' (which lacks a "public" version).  There is a
+syntax-case macro module (hygienic), but that macro system is written
+in Scheme and makes loading time extend even further beyond it's
+current unacceptable level.
+
+Guile macros are not compatible with Guile's module system.  If you
+export a macro, you need to explicitly export all bindings which it
+uses.  This needs to be fixed.
+
+It might be benefitial to separate memoization and execution to better
+support macro expansion and compile time optimizations.  The result of
+the macro expansion and memoization pass could be permanentaly stored
+on disk to reduce the load time of large programs.  This would also
+make the integration of a real compiler easier.  See next point.
+
+** Compiler
+
+Hobbit doesn't support all of the Guile language, produces inefficient
+code, and is a very unstructured program which can't be developed
+further.
+
+It iss very important that the compiler and interpreter agree as much
+as possible on the language they're implementing.  Users should be
+able to write code, run it in the interpreter, and then just switch
+over to the compiler and have everything work just as it did before.
+
+To make this possible, the compiler and interpreter should share as
+much code as possible.  For example, the module system should be
+designed to support both.  They should use the same parser and the
+same macro expander.
+
+** CORBA
+
+The way many of the major applications in the GNOME/Gtk+ world are
+moving is this:
+
+  Core application code is written in C or some other similarly
+  low-level langauge.
+
+  However, internally it consists of Bonobo components.
+
+  Bonobo components should in theory be accessible from any language
+  (someone really ought to write ORBit-guile) and can be recomposed in
+  ways other how the application originally intended.
+
+Thus, Gimp and Gnumeric will eventually in effect provide pieces that
+can be used from Guile (and other langauges) and recombined; however,
+these components will be written to the Bonobo API, not the Guile API,
+and will require a CORBA mapping for the target language to work.
+
+There are advantages and disadvantages to doing things this way as
+compared to writing Guile modules; but in either case we must be
+prepared to play in this brave new world of components by ensuring
+Guile has the proper tools available, because I don't think we are
+going to convince the GNOME people that Guile modules provide all they
+want from a component model.
+
+** POSIX threads support
+
+XXX
+
+** Faster GC
+
+We hope so.  If someone came up with a running GC that's faster than
+what we've got now, that would be extremely interesting.  But this
+isn't a primary focus.
+
+** Test suite
+
+XXX
+
+** Internationalization/multilingualization
+
+XXX
+
+** Integration of Guile into GNU programs
+
+XXX
+
+*** Emacs
+
+XXX
+
+*** The Gimp
+
+XXX
+
+** Soft typing
+
+XXX - combine with compiler section?
+
+** Importing changes from SCM
+
+XXX
+
+** Guile module repository
+
+One is to provide a better public face for Guile, and encourage people
+to contribute useful extensions. This can be achieved by providing a
+repository and managed namespace along the lines of CPAN.
+
+** More frequent releases
+
+We will try to make Guile releases more frequently.
+
+------------------- XXX - add the following to HACKING?
+
+** The CVS repository
+
+*** The current CVS version of Guile should always compile
+
+The current CVS version of Guile should always compile and not contain
+major bugs.
+
+*** Applying patches
+
+A Guile developer should always fully understand the code in a patch
+which he applies, and is responsible for the quality of the applied
+patch.
+
+*** Experimental code
+
+Experimental code should be kept in the local working copy or
+committed onto a branch.  The only exception is when some kind of
+feedback is needed from other developers or users.