/[guile]/guile/workbook/policy/plans.text
ViewVC logotype

Contents of /guile/workbook/policy/plans.text

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations) (download)
Sun Mar 24 00:20:19 2002 UTC (22 years, 1 month ago) by ttn
Branch: MAIN
CVS Tags: HEAD
Initial revision

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.

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26