guile-user
[Top][All Lists]
Advanced

[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"






reply via email to

[Prev in Thread] Current Thread [Next in Thread]