[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
the future of Guile
From: |
Marco Maggi |
Subject: |
the future of Guile |
Date: |
Tue, 4 Dec 2007 07:50:51 +0100 |
Ciao,
I think that it is time for a chat on the future of Guile.
It is a difficult topic, but: the sooner, the better. The
plan I outline below requires a lot of work and a lot of
discussion, and I can volunteer only for some of it. But of
what use is the silence?
It seems clear to me that Guile cannot compete in terms of
speed with projects like PLT Scheme, Ikarus and YouNameIt
Scheme with a native/JIT/VM/TheNext compiler.
But it does not have to because, like it or not, Guile is a
language for extensions. With this in mind...
Guidelines
----------
1. Guile as a lightweight choice.
2. Simplicity of the C interface.
3. For Guile 2.0 backwards compatibility at the C level can
be broken. Freely. No shame. No blame.
Concrete goals
--------------
1. ISO C99, can we look forward?
1a. Why functions like SIN have a Scheme implementation for
complex numbers when standard C has "csin"?
2. GOOPS always there.
2a. It is fine to have both procedures and generic
functions, but the default for Guile's C coded
procedures must be primitive generic. Non-primitive
generics are allowed as exceptions (case: READ is a
primitive procedure, dunno why).
3. Everything must be a SMOB: ports, values, classes,
instances. We can fight over procedures.
3a. The limit on SMOB type number must be destroyed.
3b. Death to structs! IMO they were "an attempt", but the
resulting code is awful (sorry, but can you disagree?).
3c. Every SMOB must have a class and an optional list of
superclasses, to allow for methods dispatching. This is
not meant to be an attempt to "corrupt" the concept of
class, but a mean to extend methods dispatching.
4. If a garbage collector allows to remove the need for
"scm_remember_upto_here" it must be adopted even if it
makes Guile slower and it raises memory usage a bit (or
more than a bit).
5. Guile must be loadable/unloadable as a shared library.
Use case: once I have read a configuration file or a sexp
data file, I do not need it anymore.
5a. A lighter feature would be useful, too: to collect all
the allocated SMOBs (running GC twice, guardians can
release async resources). It would be optional, so it is
all right to have situations in which this is forbidden.
6. More modularity.
6a. All the non-string ports should go into a loadable
module.
6b. The networking stuff should go into a loadable module.
6c. GMP support should go into a loadable module (do not
nuke my mailbox, please).
6d. Floating point math procedures should go into a loadable
module. Once they are there, more functions can be added
(from the standard C library and not) and a "long
double" SMOB can be put in, too.
6e. Records should go into a loadable module.
7. Every feature can be added as a loadable module.
7a. It makes no sense to discuss if Guile should go R6RS or
not. The only meaningful discussion is about which
hooks are needed in Guile's code to make those features
available as loadable modules. (Yes, this is
difficult).
8. Hackability of the core. If nobody understands it...
8a. Ludovic, do you still have that patch that reduces the
size of the evaluator? I do not want to hurt anyone's
feelings, but I do not understand why it was rejected.
8b. There are struct types in the core whose name is not
prefixed with "scm_t_" (example: scm_metaclass_standard)
this should be fixed. (Yes, I am a nazi with other
people's code and I allow mine to become wastesource.)
8c. This is for my own ego: yeah, yeah, yeah! Define:
typedef SCM scm_t;
Emacs font locking kisses "scm_t" automatically.
Tough ones
----------
1. TCL has nice programs that allow to distribute single
file auto-extracting-and-running archives holding the
core executable, shared libraries, pure TCL modules and
some data files (search for "tclkit").
2. Resurrect Serveez.
3. Resurrect SCWM (Scheme Constraints Window Manager).
--
Marco Maggi
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"
- the future of Guile,
Marco Maggi <=
- Re: the future of Guile, Stephen Compall, 2007/12/04
- Re: the future of Guile, Ludovic Courtès, 2007/12/04
- Re: the future of Guile, Neil Jerram, 2007/12/04
- Re: the future of Guile, Andy Wingo, 2007/12/05
- Re: the future of Guile, Mikael Djurfeldt, 2007/12/06