unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
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


             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).