Re: the future of Guile

[Ludovic Courtès]

Hi,

"Marco Maggi" <address@hidden> writes:

> But it does not have to  because, like it or not, Guile is a
> language for extensions. With this in mind...

Right, although I question the "language for extensions" paradigm: why
would you choose language Y for "extensions" and language X for the
rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently
makes programs in language Y "slower".  :-)

(Of course, language X allows you to re-use lots of libraries and tools,
so you definitely don't want to throw it away, but at least you want to
reduce the amount of code written in X.)

> 3. For Guile 2.0 backwards  compatibility at the C level can
>    be broken. Freely. No shame. No blame.

As Stephen suggested, we have to be cautious here.

> 2. GOOPS always there. 

GOOPS is nice at times, but it's also very "unschemey" in spirit,
relying on hard-to-follow side-effects for a lot of core operations (see
the `define-method' mess in G-Wrap), and biased towards an imperative
programming style.  I used to be a big fan, but I've become more and
more suspicious.

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

What would it buy you if `read' were a primitive generic?  `write' is
certainly useful as a generic, but I don't see the benefit of `read' as
a generic.

Besides, if turning primitives into primitive-generics doesn't slow down
Guile startup, then we can go for it.

> 3a. The limit on SMOB type number must be destroyed.

It's gonna be hard since we have only 8 bits available currently (BTW, I
saw your patch that adds support for sub-SMOBs but it looks complex to
me---more on that later).

> 3b. Death to  structs!  IMO they were "an  attempt", but the
>     resulting code is awful (sorry, but can you disagree?). 

We may have to keep it, at least for the sake of backward compatibility.

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

As you noted in a recent post, SMOBs types have an associated class when
GOOPS is loaded.  So what else do you want?

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

Well, `scm_remember_upto_here ()' is rarely need anyway.

> 6. More modularity. 

I think we could almost have one module per C source file, e.g.,
`socket', `posix', `filesys', etc. (however, we definitely don't want
one shared library per module, because of the overhead).  We could them
set up a backward-compatible namespace that pulls all of them, while
still leaving the opportunity to execute code in a minimal environment
where only core primitives are available.

> 6c. GMP  support should  go into a  loadable module  (do not
>     nuke my mailbox, please).

No way (see Stephen's reply).  :-)

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

Likewise.

> 6e. Records should go into a loadable module.

SRFI-9 records?  They are already in 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).

Agreed.

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

It did not really make it smaller, it just splitted it into several
parts.  The main arguments against it were that it splitted things badly
and that moving code around precludes auditing through diffs:

  http://lists.gnu.org/archive/html/guile-devel/2007-02/msg00040.html

> 8b. There  are struct  types in the  core whose name  is not
>     prefixed with "scm_t_" (example: scm_metaclass_standard)
>     this  should be  fixed.

Right.

> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>
>       typedef SCM scm_t;
>
>     Emacs font locking kisses "scm_t" automatically.

I'm afraid it's a bit too late, and we don't want two names for one
thing.

Thanks,
Ludovic.