1 |
This file describes the current status and future plans for Guile development. |
2 |
|
3 |
* Status |
4 |
|
5 |
To give you an idea how far we are from the things described above, |
6 |
here is the status of some topics. Guile used to suck, but it doesn't |
7 |
any more. |
8 |
|
9 |
** Documentation |
10 |
|
11 |
XXX - Losta stuff, and talk also about updating the web page. |
12 |
|
13 |
** Object oriented programming |
14 |
|
15 |
Guile's object system is GOOPS. XXX - Some notes about |
16 |
characteristics and motivations. |
17 |
|
18 |
** Multithreading |
19 |
|
20 |
At the moment, Guile supports co-operative threading on several |
21 |
platforms. We do *not* support true kernel threads at present, not |
22 |
because we don't think that would be way cool, but because it's |
23 |
really, really hard. We're taking continually taking steps towards |
24 |
that goal, however. |
25 |
|
26 |
Current status is that necessary basic changes to the garbage |
27 |
collector and the signal handling has been done. (Few are aware of |
28 |
it, but the SCM_DEFER_INTS/SCM_ALLOW_INTS macros no longer have any |
29 |
effect!) |
30 |
|
31 |
The major remaining work is to protect common resources using mutecis. |
32 |
|
33 |
*** Using Guile's COOP threads in a POSIX threaded application |
34 |
|
35 |
A recent change has made it possible to mix use of Guile's COOP |
36 |
threads and POSIX threads in a single application. This is useful, |
37 |
since some GNOME libraries links with pthreads by default. (Guile |
38 |
still has to run in a single POSIX thread, and the two thread systems |
39 |
needs to use independent sets of thread synchronization mechanisms, |
40 |
however.) |
41 |
|
42 |
** Graphical toolkit |
43 |
|
44 |
You can access Gtk+ from Guile by using the (separate) guile-gtk |
45 |
package. The basic machinery of guile-gtk is mostly done but |
46 |
individual features of Gtk+ are missing. Adding these features is |
47 |
mostly the job of taking a look whether they are safe to export in |
48 |
unmodified form and when that is the case, writing a couple of easy |
49 |
lines of descriptions for the feature. This is mostly busy work. |
50 |
|
51 |
XXX - guile-tcltk? |
52 |
|
53 |
* Near Future |
54 |
|
55 |
What is planned for the near future. |
56 |
|
57 |
** Breakpoints and single-stepping in the debugger |
58 |
|
59 |
Guile now has a debugger (try `(debug)'). We are planning to |
60 |
implement breakpoints and single-stepping, and then announce the |
61 |
debugger in README file and documentation. |
62 |
|
63 |
** A new module system |
64 |
|
65 |
Integration of Jost Boekemeiers environment implementation. Greg |
66 |
Badros has promised to try to integrate them. |
67 |
|
68 |
On top of that, a new module system will be implemented, but: |
69 |
1) We're not settled yet, |
70 |
2) we're really trying to settle it, and |
71 |
3) we're discovering why the rest of the Scheme scene isn't |
72 |
settled on this issue either. |
73 |
|
74 |
There will be a C API to the new module system. |
75 |
|
76 |
** Factorization of Guile into function libraries |
77 |
|
78 |
Although Guile is meant to support composing a system from modules |
79 |
well, it does not make use of this principle itself. The core is |
80 |
quite monolithic and includes a lot of things that could be separated |
81 |
out. |
82 |
|
83 |
We will be moving such things as networking, posix and regular |
84 |
expression support to separate modules instead of having them all in |
85 |
the root namespace. |
86 |
|
87 |
** Faster startup |
88 |
|
89 |
We will make Guile start up quicker. Guile's current slow startup is |
90 |
primarily due to 1. inefficient code in a time-critical place in the |
91 |
current module system, and, 2. that too much code is loaded at |
92 |
startup. |
93 |
|
94 |
** Translators |
95 |
|
96 |
*** Framework |
97 |
|
98 |
Framework making it easy for application developers to add new |
99 |
translations. This includes the engines from flex and bison + a |
100 |
way to add new grammars from Scheme. |
101 |
|
102 |
*** C-like syntax for Scheme |
103 |
*** elisp |
104 |
*** tcl |
105 |
*** python |
106 |
*** Java |
107 |
|
108 |
* The Guile wishlist |
109 |
|
110 |
** A byte compiler! |
111 |
|
112 |
New developments have made it possible to create very fast byte code |
113 |
interpreters. We are willing to replace the current Guile evaluator |
114 |
when a suitable candidate byte code interpreters turns up. |
115 |
|
116 |
It should fulfill the following criteria: |
117 |
|
118 |
*** It should be or promise to become significantly faster than the |
119 |
current evaluator. |
120 |
|
121 |
*** It should support or promise to support debugging and backtraces |
122 |
not much less informative than the current ones. |
123 |
|
124 |
*** It should support conservative GC. |
125 |
|
126 |
*** It should be possible to integrate with large parts of the |
127 |
existing Guile infrastructure. |
128 |
|
129 |
** Revision and stabilization of interfaces |
130 |
|
131 |
Along with the updating the documentation, we should clean up the |
132 |
interfaces of Guile. |
133 |
|
134 |
It should be well defined which existing Scheme procedures and C |
135 |
functions and macros are supported as part of the "Guile language" and |
136 |
which are temporary procedures used in the implementation of Guile or |
137 |
historical remnants. |
138 |
|
139 |
** Full R5RS compliance |
140 |
|
141 |
XXX |
142 |
|
143 |
** SRFIs |
144 |
|
145 |
XXX |
146 |
|
147 |
** Reorganization of the numeric code |
148 |
|
149 |
Numeric tower |
150 |
|
151 |
3. Introduce a subclass of <generic> called <arithmetic-generic>. |
152 |
|
153 |
Such objects contain 7 pointers to C functions handling the argument |
154 |
combinations (), (INUM), (REAL), (INUM, INUM), (REAL, INUM), |
155 |
(INUM, REAL) and (REAL, REAL). |
156 |
|
157 |
When an <arithmetic-generic> is applied, it first uses simple |
158 |
if-statements to dispatch onto one of these "primitive methods". |
159 |
If that fails, it behaves as an ordinary generic, i.e., it does |
160 |
type dispatch. |
161 |
|
162 |
4. Turn all standard Guile arithmetic, and comparison operators into |
163 |
<arithmetic-generic>s and break up numbers.c into independent |
164 |
modules. |
165 |
|
166 |
After this, we can easily add new types to the numeric tower. The new |
167 |
types will be handled a little bit slower than INUMs and REALs, but I |
168 |
think it will be fast enough. |
169 |
|
170 |
Some fundamental changes have already been done that make floating |
171 |
point calculations more efficient. |
172 |
|
173 |
** Low-level support for hygienic macros |
174 |
|
175 |
Instead of a well integrated support for hygieneic macros, Guile |
176 |
provides three redundant ways of defining unhygienic macros: |
177 |
`procedure->macro', `defmacro' (with `defmacro-public'), and, |
178 |
`define-macro' (which lacks a "public" version). There is a |
179 |
syntax-case macro module (hygienic), but that macro system is written |
180 |
in Scheme and makes loading time extend even further beyond it's |
181 |
current unacceptable level. |
182 |
|
183 |
Guile macros are not compatible with Guile's module system. If you |
184 |
export a macro, you need to explicitly export all bindings which it |
185 |
uses. This needs to be fixed. |
186 |
|
187 |
It might be benefitial to separate memoization and execution to better |
188 |
support macro expansion and compile time optimizations. The result of |
189 |
the macro expansion and memoization pass could be permanentaly stored |
190 |
on disk to reduce the load time of large programs. This would also |
191 |
make the integration of a real compiler easier. See next point. |
192 |
|
193 |
** Compiler |
194 |
|
195 |
Hobbit doesn't support all of the Guile language, produces inefficient |
196 |
code, and is a very unstructured program which can't be developed |
197 |
further. |
198 |
|
199 |
It iss very important that the compiler and interpreter agree as much |
200 |
as possible on the language they're implementing. Users should be |
201 |
able to write code, run it in the interpreter, and then just switch |
202 |
over to the compiler and have everything work just as it did before. |
203 |
|
204 |
To make this possible, the compiler and interpreter should share as |
205 |
much code as possible. For example, the module system should be |
206 |
designed to support both. They should use the same parser and the |
207 |
same macro expander. |
208 |
|
209 |
** CORBA |
210 |
|
211 |
The way many of the major applications in the GNOME/Gtk+ world are |
212 |
moving is this: |
213 |
|
214 |
Core application code is written in C or some other similarly |
215 |
low-level langauge. |
216 |
|
217 |
However, internally it consists of Bonobo components. |
218 |
|
219 |
Bonobo components should in theory be accessible from any language |
220 |
(someone really ought to write ORBit-guile) and can be recomposed in |
221 |
ways other how the application originally intended. |
222 |
|
223 |
Thus, Gimp and Gnumeric will eventually in effect provide pieces that |
224 |
can be used from Guile (and other langauges) and recombined; however, |
225 |
these components will be written to the Bonobo API, not the Guile API, |
226 |
and will require a CORBA mapping for the target language to work. |
227 |
|
228 |
There are advantages and disadvantages to doing things this way as |
229 |
compared to writing Guile modules; but in either case we must be |
230 |
prepared to play in this brave new world of components by ensuring |
231 |
Guile has the proper tools available, because I don't think we are |
232 |
going to convince the GNOME people that Guile modules provide all they |
233 |
want from a component model. |
234 |
|
235 |
** POSIX threads support |
236 |
|
237 |
XXX |
238 |
|
239 |
** Faster GC |
240 |
|
241 |
We hope so. If someone came up with a running GC that's faster than |
242 |
what we've got now, that would be extremely interesting. But this |
243 |
isn't a primary focus. |
244 |
|
245 |
** Test suite |
246 |
|
247 |
XXX |
248 |
|
249 |
** Internationalization/multilingualization |
250 |
|
251 |
XXX |
252 |
|
253 |
** Integration of Guile into GNU programs |
254 |
|
255 |
XXX |
256 |
|
257 |
*** Emacs |
258 |
|
259 |
XXX |
260 |
|
261 |
*** The Gimp |
262 |
|
263 |
XXX |
264 |
|
265 |
** Soft typing |
266 |
|
267 |
XXX - combine with compiler section? |
268 |
|
269 |
** Importing changes from SCM |
270 |
|
271 |
XXX |
272 |
|
273 |
** Guile module repository |
274 |
|
275 |
One is to provide a better public face for Guile, and encourage people |
276 |
to contribute useful extensions. This can be achieved by providing a |
277 |
repository and managed namespace along the lines of CPAN. |
278 |
|
279 |
** More frequent releases |
280 |
|
281 |
We will try to make Guile releases more frequently. |
282 |
|
283 |
------------------- XXX - add the following to HACKING? |
284 |
|
285 |
** The CVS repository |
286 |
|
287 |
*** The current CVS version of Guile should always compile |
288 |
|
289 |
The current CVS version of Guile should always compile and not contain |
290 |
major bugs. |
291 |
|
292 |
*** Applying patches |
293 |
|
294 |
A Guile developer should always fully understand the code in a patch |
295 |
which he applies, and is responsible for the quality of the applied |
296 |
patch. |
297 |
|
298 |
*** Experimental code |
299 |
|
300 |
Experimental code should be kept in the local working copy or |
301 |
committed onto a branch. The only exception is when some kind of |
302 |
feedback is needed from other developers or users. |