Re: Why do we spend time on Emacs on Guile?

[Thien-Thi Nguyen]

   From: Werner LEMBERG <address@hidden>
   Date: Sat, 17 Aug 2002 00:46:00 +0200 (CEST)

   LilyPond, a music typesetting program (www.lilypond.org), uses Guile.
   While following the development of LilyPond I see that Guile itself
   isn't a stable target yet: It simply happens too often that the
   authors of LilyPond have to add some glue code to make it work with
   different versions of Guile.

i've spewed greatly on the guile lists wrt compatibility in general (not
just for lilypond) w/o much success in curtailing that recklessness, so
i won't say much more than, yeah, that's a problem.

but it's not my problem (anymore) since i've grabbed the good stuff from
the guile HEAD and have incorporated it into a 1.4.x maintenance effort
w/ the goals specifically being compatibility and stability for client
apps.  my daily inspiration is aisleriot (the "spider" variant) which is
a lot of fun to play on a graphical display, and which links against
libguile.  i feel that breaking that game would be a poor way to show my
appreciation.

in any case, guile symbols already have extra slots for function and
plists -- actually that would be "msymbols" (from libguile/symbols.h):

/* SCM_LENGTH(SYM) is the length of SYM's name in characters, and
   SCM_CHARS(SYM) is the address of the first character of SYM's name.

   Beyond that, there are two kinds of symbols: ssymbols and msymbols,
   distinguished by the 'S' bit in the type.

   Ssymbols are just uniquified strings.  They have a length, chars,
   and that's it.  They use the scm_tc7_ssymbol tag (S bit clear).

   Msymbols are symbols with extra slots.  These slots hold a property
   list and a function value (for Emacs Lisp compatibility), and a hash
   code.  They use the scm_tc7_msymbol tag.

   [...] */

the module system uses the aforementioned "variable" construct for
bindings but there's no reason it couldn't be made to also recognize and
use msymbols.  perhaps someone can explain why this existing support
should be ignored.

thi