From: "Marco Maggi" <marco.maggi-ipsu@poste.it>
To: "guile-user" <guile-user@gnu.org>
Subject: the future of Guile
Date: Tue, 4 Dec 2007 07:50:51 +0100 [thread overview]
Message-ID: <JSIJ0R$54F55A518E52A4B6C8A09A3378AEEDDD@poste.it> (raw)
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"
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next reply other threads:[~2007-12-04 6:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-04 6:50 Marco Maggi [this message]
2007-12-04 8:48 ` the future of Guile Stephen Compall
2007-12-04 12:41 ` Ludovic Courtès
2007-12-04 14:50 ` Bill Schottstaedt
2007-12-04 15:30 ` Ludovic Courtès
2007-12-04 23:00 ` Neil Jerram
2007-12-05 23:11 ` Andy Wingo
2007-12-06 19:48 ` Mikael Djurfeldt
[not found] <F8.1B.18780.B4965574@avas11>
2007-12-04 15:55 ` the future of guile Daniel Llorens del Río
[not found] <cmu-lmtpd-7104-1196779864-1@mail-imap2.uio.no>
2007-12-04 18:08 ` the future of Guile Kjetil S. Matheussen
2007-12-04 18:34 ` Kjetil S. Matheussen
2007-12-04 20:06 ` Roland Orre
2007-12-04 20:42 ` Ludovic Courtès
2007-12-04 22:30 ` Kjetil S. Matheussen
[not found] <34.F3.20110.D6985574@avas19>
2007-12-04 19:54 ` the future of guile Daniel Llorens del Río
-- strict thread matches above, loose matches on Subject: below --
2007-12-05 9:01 the future of Guile Marco Maggi
2007-12-05 14:19 ` Roland Orre
2007-12-05 20:28 ` Ludovic Courtès
2007-12-05 15:40 Mike Gran
2007-12-05 16:05 ` Julian Graham
2007-12-05 16:18 ` Daniel Ridge
2007-12-05 20:41 ` Ludovic Courtès
2007-12-05 21:02 Marco Maggi
2007-12-05 22:32 Marco Maggi
2007-12-05 22:56 ` Ludovic Courtès
[not found] <cmu-lmtpd-27643-1196871540-1@mail-imap2.uio.no>
2007-12-06 14:52 ` Kjetil S. Matheussen
2007-12-07 6:28 Marco Maggi
[not found] <cmu-lmtpd-4316-1197047238-3@mail-imap2.uio.no>
2007-12-07 17:42 ` Kjetil S. Matheussen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='JSIJ0R$54F55A518E52A4B6C8A09A3378AEEDDD@poste.it' \
--to=marco.maggi-ipsu@poste.it \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).