From 8e2488ffae40c1f13dfbadb118ba106df9e4bc43 Mon Sep 17 00:00:00 2001 From: Mikael Djurfeldt Date: Wed, 26 Jul 2000 05:08:23 +0000 Subject: [PATCH] *** empty log message *** --- devel/policy/plans.text | 278 ---------------------------------------- devel/tasks.text | 4 + 2 files changed, 4 insertions(+), 278 deletions(-) rewrite devel/policy/plans.text (100%) diff --git a/devel/policy/plans.text b/devel/policy/plans.text dissimilarity index 100% index 93c4791a0..e69de29bb 100644 --- a/devel/policy/plans.text +++ b/devel/policy/plans.text @@ -1,278 +0,0 @@ -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 called . - - 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 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 - 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. diff --git a/devel/tasks.text b/devel/tasks.text index e29c88799..a95ecc88b 100644 --- a/devel/tasks.text +++ b/devel/tasks.text @@ -45,6 +45,10 @@ rlb ryanw +** generic translator support + +mdj + ** integration of Jost's environments dirk -- 2.20.1