devel/policy/plans.text

   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 XXX - ???
  97
  98 *** C-like syntax for Scheme
  99 *** elisp
 100 *** tcl
 101 *** python
 102
 103 * The Guile wishlist
 104
 105 ** Revision and stabilization of interfaces
 106
 107 Along with the updating the documentation, we should clean up the
 108 interfaces of Guile.
 109
 110 It should be well defined which existing Scheme procedures and C
 111 functions and macros are supported as part of the "Guile language" and
 112 which are temporary procedures used in the implementation of Guile or
 113 historical remnants.
 114
 115 ** Full R5RS compliance
 116
 117 XXX
 118
 119 ** SRFIs
 120
 121 XXX
 122
 123 ** Reorganization of the numeric code
 124
 125 Numeric tower
 126
 127 3. Introduce a subclass of <generic> called <arithmetic-generic>.
 128
 129    Such objects contain 7 pointers to C functions handling the argument
 130    combinations (), (INUM), (REAL), (INUM, INUM), (REAL, INUM),
 131    (INUM, REAL) and (REAL, REAL).
 132
 133    When an <arithmetic-generic> is applied, it first uses simple
 134    if-statements to dispatch onto one of these "primitive methods".
 135    If that fails, it behaves as an ordinary generic, i.e., it does
 136    type dispatch.
 137
 138 4. Turn all standard Guile arithmetic, and comparison operators into
 139    <arithmetic-generic>s and break up numbers.c into independent
 140    modules.
 141
 142 After this, we can easily add new types to the numeric tower.  The new
 143 types will be handled a little bit slower than INUMs and REALs, but I
 144 think it will be fast enough.
 145
 146 Some fundamental changes have already been done that make floating
 147 point calculations more efficient.
 148
 149 ** Low-level support for hygienic macros
 150
 151 Instead of a well integrated support for hygieneic macros, Guile
 152 provides three redundant ways of defining unhygienic macros:
 153 `procedure->macro', `defmacro' (with `defmacro-public'), and,
 154 `define-macro' (which lacks a "public" version).  There is a
 155 syntax-case macro module (hygienic), but that macro system is written
 156 in Scheme and makes loading time extend even further beyond it's
 157 current unacceptable level.
 158
 159 Guile macros are not compatible with Guile's module system.  If you
 160 export a macro, you need to explicitly export all bindings which it
 161 uses.  This needs to be fixed.
 162
 163 It might be benefitial to separate memoization and execution to better
 164 support macro expansion and compile time optimizations.  The result of
 165 the macro expansion and memoization pass could be permanentaly stored
 166 on disk to reduce the load time of large programs.  This would also
 167 make the integration of a real compiler easier.  See next point.
 168
 169 ** Compiler
 170
 171 Hobbit doesn't support all of the Guile language, produces inefficient
 172 code, and is a very unstructured program which can't be developed
 173 further.
 174
 175 It iss very important that the compiler and interpreter agree as much
 176 as possible on the language they're implementing.  Users should be
 177 able to write code, run it in the interpreter, and then just switch
 178 over to the compiler and have everything work just as it did before.
 179
 180 To make this possible, the compiler and interpreter should share as
 181 much code as possible.  For example, the module system should be
 182 designed to support both.  They should use the same parser and the
 183 same macro expander.
 184
 185 ** CORBA
 186
 187 The way many of the major applications in the GNOME/Gtk+ world are
 188 moving is this:
 189
 190   Core application code is written in C or some other similarly
 191   low-level langauge.
 192
 193   However, internally it consists of Bonobo components.
 194
 195   Bonobo components should in theory be accessible from any language
 196   (someone really ought to write ORBit-guile) and can be recomposed in
 197   ways other how the application originally intended.
 198
 199 Thus, Gimp and Gnumeric will eventually in effect provide pieces that
 200 can be used from Guile (and other langauges) and recombined; however,
 201 these components will be written to the Bonobo API, not the Guile API,
 202 and will require a CORBA mapping for the target language to work.
 203
 204 There are advantages and disadvantages to doing things this way as
 205 compared to writing Guile modules; but in either case we must be
 206 prepared to play in this brave new world of components by ensuring
 207 Guile has the proper tools available, because I don't think we are
 208 going to convince the GNOME people that Guile modules provide all they
 209 want from a component model.
 210
 211 ** POSIX threads support
 212
 213 XXX
 214
 215 ** Faster GC
 216
 217 We hope so.  If someone came up with a running GC that's faster than
 218 what we've got now, that would be extremely interesting.  But this
 219 isn't a primary focus.
 220
 221 ** Test suite
 222
 223 XXX
 224
 225 ** Internationalization/multilingualization
 226
 227 XXX
 228
 229 ** Integration of Guile into GNU programs
 230
 231 XXX
 232
 233 *** Emacs
 234
 235 XXX
 236
 237 *** The Gimp
 238
 239 XXX
 240
 241 ** Soft typing
 242
 243 XXX - combine with compiler section?
 244
 245 ** Importing changes from SCM
 246
 247 XXX
 248
 249 ** Guile module repository
 250
 251 One is to provide a better public face for Guile, and encourage people
 252 to contribute useful extensions. This can be achieved by providing a
 253 repository and managed namespace along the lines of CPAN.
 254
 255 ** More frequent releases
 256
 257 We will try to make Guile releases more frequently.
 258
 259 ------------------- XXX - add the following to HACKING?
 260
 261 ** The CVS repository
 262
 263 *** The current CVS version of Guile should always compile
 264
 265 The current CVS version of Guile should always compile and not contain
 266 major bugs.
 267
 268 *** Applying patches
 269
 270 A Guile developer should always fully understand the code in a patch
 271 which he applies, and is responsible for the quality of the applied
 272 patch.
 273
 274 *** Experimental code
 275
 276 Experimental code should be kept in the local working copy or
 277 committed onto a branch.  The only exception is when some kind of
 278 feedback is needed from other developers or users.