emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile in Emacs


From: John Wiegley
Subject: Re: Guile in Emacs
Date: Wed, 14 Apr 2010 09:30:38 -0400

On Apr 14, 2010, at 1:02 AM, Richard Stallman wrote:

> Common Lisp is extremely complicated and ugly.  When I wrote GNU Emacs
> I had just finished implementing Common Lisp, and I did not like it
> much.  It would bloat Emacs terribly, and documenting it would be hard
> too.

Do you mean the libraries are?  Because the core syntax of CL is pretty simple. 
 Also, with Scheme there are several core semantic differences from Emacs Lisp: 
a) It's a Lisp-1, and b) the difference between nil, () and #f.  Those two 
right there can make porting any significant Emacs application extremely 
difficult.

As for Common Lisp -- or let's say, a functional subset for the purpose of 
making it an Emacs extension language -- if, as some suggest, it's worthwhile 
to ignore existing code and start afresh, why isn't a project like CLmacs more 
interesting?  It's very Emacs like, but lacks all the useful libraries which 
make Emacs what it is.

Personally I think adopting a new internal language for Emacs, just so GNU can 
have a common scripting language, is somewhat ludicrous.  Emacs Lisp has proven 
itself to be incredibly useful, as shown by the enormous number of contributors 
and extensive library of code -- some of which has seen extensive usage for a 
decade or more now.  It may have its warts, but so will any system by the time 
its users are done with it.

Lastly, I'm not at all convinced Emacs Lisp needs multithreading.  I would 
prefer a coarser model of process separation to allow things like Gnus to run 
in tandem with other tasks.  It would be nice if a wholly separate process 
could connect to the frames/windows/buffers (but not symbol space) of a master 
Emacs process.  I was just considering yesterday the truly scary-to-debug 
scenarios that come up when you realize dynamic variables can change mid-form, 
or that hooks might run while other hooks are executing.  There is so much code 
that depends on sequence of execution that I think multithreading could cause 
us stability headaches for years and years.

John



reply via email to

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