Why do we spend time on Emacs on Guile?

Why do we spend time on Emacs on Guile?

[Kim F. Storm]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:
> No, I still think basing Emacs on Guile is a very bad idea.

And I thought I was alone :-)

I really don't see the point in spending a lot of time on 
"Emacs on Guile" which IMHO seems like a pretty academic project.  

Emacs Lisp has allowed users and hackers to implement zillions of
brilliant add-on packages; what benefits (besides the academic ones)
will switching to Guile give us?

As Richard usually points out, our efforts should be on changes which
have a benefit for the users of emacs, rather than the convenience of
the "emacs hackers".  AFAICS, switching to Guile has _ZERO_ benefits
for the emacs users.

What about a poll...:

How many of the members on emacs-devel plan to switch to Guile once it
is available?

Why would you do that?

Have you ever programmed in Guile/Scheme ?  How much?

I doubt very many existing Emacs Lisp packages will be converted to
Guile, so what are the performance issues of not doing so if Emacs
uses Guile internally?  

From the discussions on the list, it seems Guile's data model doesn't
really fit very well with Emacs Lisp anyway.

++kfs

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

[Thien-Thi Nguyen]

storm@cua.dk (Kim F. Storm) writes:

   How many of the members on emacs-devel plan to switch to Guile once
   it is available?

if it's done right, guile availability won't require switching; it will
just Be There.  of course, there are ways to Be quite ugly but that's
another question.  it should always be possible to write elisp programs
and expect emacs to execute them.

   Why would you do that?

for one thing, guile scheme object properties are very general (at
least, historically).  most anything can be a property as well as a
value.  it's easy to build trees w/ this kind of facility.

   Have you ever programmed in Guile/Scheme ?  How much?

check out http://www.glug.org/maint/ for ongoing travails...  also
relevant to this list would be a google search for "gap-buffer.scm" and
in the same directory edit.scm.  see gpgutils.scm for example usage of
edit.scm (warning: not suitable for either scheme or elisp purists ;-).

   I doubt very many existing Emacs Lisp packages will be converted to
   Guile, so what are the performance issues of not doing so if Emacs
   uses Guile internally?  

it used to be you could compile a large subset of guile scheme to a
shared object library (.so file) and of course load that.  perhaps that
will be possible again in the future.  see latest SCM by Aubrey Jaffer.

thi

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

[D. Goel]

storm@cua.dk (Kim F. Storm) writes:

> How many of the members on emacs-devel plan to switch to Guile once it
> is available?

i am not sure i qualify as a developer :), but i certainly want to try
guile out, and even explore switching to guile instead of elisp.

> 
> Why would you do that?

For one, i kinda understand guile will be a much more universal
language than Elisp..  and will be interoperable with several
applications and languages in the long run..  It will be the standard
'GNU extension language'..


> Have you ever programmed in Guile/Scheme ?  How much?

yes.  not much.   scheme is nice :) 

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

[Sam Steingold]

> * In message <5xk7mrywnt.fsf_-_@kfs2.cua.dk>
> * On the subject of "Why do we spend time on Emacs on Guile?"
> * Sent on 16 Aug 2002 11:34:30 +0200
> * Honorable storm@cua.dk (Kim F. Storm) writes:
>
> gerd.moellmann@t-online.de (Gerd Moellmann) writes:
> > No, I still think basing Emacs on Guile is a very bad idea.
> And I thought I was alone :-)

that makes 3 of us! :-)

> Emacs Lisp has allowed users and hackers to implement zillions of
> brilliant add-on packages; what benefits (besides the academic ones)
> will switching to Guile give us?

There are two separate issues here:

1. should Emacs use Emacs-Lisp or some other language?

2. if yes, what should that language be?

(1): Just like C is a good "UNIX extension language", but not really
   suitable for large applications, Emacs lisp is a nice Emacs extension
   language, but it is not really good for large-scale application.
   So it should be replaced by a high-level language better suited for
   solving complex problems (like Calc, Gnus, JDE &c)

   A simple example: half the packages that come with Emacs re-implement
   at least one CL function (e.g., `find' with keywords) they need but
   cannot use because of the requirement of not using cl.el at run time.

(2): Guile is a nice small teaching language which lacks features
   necessary for buiding large applications.  Yes, there are many
   extensions, but they have not been standardized yet, so using Guile
   will either require having several incompatible object systems or
   choosing one of then - and it is not clear which one (so much
   haggling lays ahead...)
   
   As I said in an earlier message, choosing Guile is discarding all
   the thought that went into Common Lisp.
   
   It is a huge mistake, which we will be paying for in the years ahead.
   
   A simple example: loading and executing Emacs Lisp in Guile appears
   to be a Really Hard Problem.  Loading and executing Emacs Lisp in
   Common Lisp was a weekend exercise for me several years ago: you can
   run Emacs Calendar under any ANSI Common Lisp (e.g.,
   <http://clisp.cons.org>) using my <CLOCC/CLLIB/elisp.lisp> (see
   <http://clocc.sf.net>).

   Two more issues:

   - size: as I said, the size of Emacs will probably descrease with
     the switch to CL because a lot of code duplication will be
     eliminated.

   - transition pangs: both syntactically and semantically Emacs Lisp
     is _much_ closer to Common Lisp than to Scheme.  It is much easier
     for an ELisp hacker to get up to speed with CL than with Scheme
     (this is from my personal experience).

CL as a language is bigger than ELisp, which, in turn, is bigger than
Scheme.
What is easier: to move from a 2 bedroom apartment to a 5 bedroom
house or to a studio (whose widow opens to an adjoining roof and which,
therefore, can be extended with the help of the friendly building
manager)?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Good programmers treat Microsoft products as damage and route around it.

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

[Werner LEMBERG]

>    Have you ever programmed in Guile/Scheme ?  How much?
> 
> check out http://www.glug.org/maint/ for ongoing travails...  also
> relevant to this list would be a google search for "gap-buffer.scm"
> and in the same directory edit.scm.  see gpgutils.scm for example
> usage of edit.scm (warning: not suitable for either scheme or elisp
> purists ;-).

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.


   Werner

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

[Richard Stallman]

Guile is the standard extensibility package of the GNU Project, All
GNU packages that include an interpreter for extensibility are
supposed to use Guile.  It is inconsistent for Emacs not to support
Guile.

It would not make sense to replace Guile with Emacs Lisp in everything
else.

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

[Sam Steingold]

> * In message <200208170450.g7H4oRf08568@wijiji.santafe.edu>
> * On the subject of "Re: Why do we spend time on Emacs on Guile?"
> * Sent on Fri, 16 Aug 2002 22:50:27 -0600 (MDT)
> * Honorable Richard Stallman <rms@gnu.org> writes:
>
> Guile is the standard extensibility package of the GNU Project, All
> GNU packages that include an interpreter for extensibility are
> supposed to use Guile.  It is inconsistent for Emacs not to support
> Guile.

Supporting Guile via compilation into Common Lisp is _much_ easier.
I.e., re-hosting Emacs on CLISP and making CLISP able to load Emacs
Lisp (done already) and Guile (should be very easy).

> It would not make sense to replace Guile with Emacs Lisp in everything
> else.

absolutely!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
What was the best thing before sliced bread?

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

[Thien-Thi Nguyen]

   From: Werner LEMBERG <wl@gnu.org>
   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

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

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Sam" == Sam Steingold <sds@gnu.org> writes:

>> * In message <200208170450.g7H4oRf08568@wijiji.santafe.edu>
>> * On the subject of "Re: Why do we spend time on Emacs on Guile?"
>> * Sent on Fri, 16 Aug 2002 22:50:27 -0600 (MDT)
>> * Honorable Richard Stallman <rms@gnu.org> writes:
Sam> >
>> Guile is the standard extensibility package of the GNU Project, All
>> GNU packages that include an interpreter for extensibility are
>> supposed to use Guile.  It is inconsistent for Emacs not to support
>> Guile.

Sam> Supporting Guile via compilation into Common Lisp is _much_ easier.
Sam> I.e., re-hosting Emacs on CLISP and making CLISP able to load Emacs
Sam> Lisp (done already) and Guile (should be very easy).

Jonathan Rees's Pseudoscheme did this many years ago, but the support
sure wasn't complete.  I'd also be surprise if this were "very" easy:
you at least need to take care of hygienic macros (possible) and
CALL-WITH-CURRENT-CONTINUATION (ermh, ..., difficult).

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla