Re: emacs with guile instead of elisp

[Andrew Archibald <aarchiba@undergrad.math.uwaterloo.ca>]

; The FSF is quite interested in replacing the Emacs Lisp interpreter
; with Guile, once a translator from Emacs Lisp to Guile is ready.  We
; will retain as much of the other Emacs code as makes sense; I expect
; we'll keep most of it.  The lisp interpreter is only a small portion
; of the C code.

What would be involved in making guile able to run elisp code? Is the
reader general enough?  What sort of (how much) new syntax/new library
procedures are necessary?  (I don't know elisp, I just write scheme
and hope emacs likes it)

What sort of efficiency issues are there?  Currently guile takes a
long time to read in source code, and unexec is fast but very
limited.  Would byte-compilation be helpful?  Would something more
general be better?  There are packages that do significant
precomputation;  if their state could be saved after a certain amount
of computation, startup time could be sharply reduced. 

How difficult would it be to make the emacs C code talk to guile? 

An additional side effect of hooking guile to emacs would be to allow
users more flexible customization/extension syntax.  It really isn't
very difficult to add a new syntax to guile.

; The major point of this project would be to allow users to program
; Emacs in languages other than Emacs Lisp (like Scheme).  It also has
; some minor advantages; for example, Guile's garbage collector is much
; easier to work with than the one presently in Emacs, because it is
; conservative.

Guile is also multithreaded.  This may be a problem for emacs code.
Actually, ideally, guile should become OS-level multithreaded.
Moreover, it should also have parallel or mostly-parallel garbage
collection.  (see http://reality.sgi.com/employees/boehm_mti/gc.html)
Currenttly the lengthy pauses for garbage collection are a serious
limitation of guile's performance. 

So, how much work/what effort would be involved in this?

Thanks,
Andrew
aarchiba@undergrad.math.uwaterloo.ca