mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-06-11 06:20:23 +02:00
*** empty log message ***
This commit is contained in:
Mikael Djurfeldt
parent
5682251bb1
commit
8e2488ffae
2 changed files with 4 additions and 278 deletions
|
|
@ -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 <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.
|
||||
|
|
@ -45,6 +45,10 @@ rlb
|
|||
|
||||
ryanw
|
||||
|
||||
** generic translator support
|
||||
|
||||
mdj
|
||||
|
||||
** integration of Jost's environments
|
||||
|
||||
dirk
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue