This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: emacs with guile instead of elisp



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

I think this is talked about somewhere on the web site.

The idea is to write a new reader for Emacs Lisp, or whatever language
you want to handle, and then write a translator from Emacs Lisp into
Scheme.  This translation is non-trivial; for example, Emacs Lisp's
`let' does dynamic binding, while Scheme's `let' does static binding.
In emacs Lisp, (car nil) is nil, whereas in Scheme, (car '()) is an
error.  So clearly, there's some non-trivial work involved here.  But
it's really just a compilation problem, where we can amend the target
architecture (Guile) to make the translation easier.

The long-term goal is to support all kinds of languages this way.
Ideally, we'd have translators for Perl and Tcl, too.  (For the sake
of discussion, we'll set aside concerns about whether Perl is
sufficiently well-defined to allow alternative implementations.  That
parser would be a killer.)

> What sort of efficiency issues are there?  Currently guile takes a
> long time to read in source code

This is because the module system is poorly implemented.

> and unexec is fast but very limited.

One thing I'd like to see, in the long term, is for Guile to evolve
into a language that allows separate compilation.  I *think* that,
once you have enough of a separation between the compile phase and the
run phase, you might be able to make the limitations of unexec go
away, because you've already got a well-defined boundary between the
phases, across which certain kinds of objects are not expected to be
live.  This boundary would be a nice place to take a dump (so to
speak).

There are alternatives to unexec, too.

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

I don't think it would be that bad, actually.  There aren't any
demands I can think of offhand that Guile makes of C code that Emacs
doesn't already follow (aside from threading issues, and some concerns
about strings and vectors getting GC'd too early), so you could pretty
much do a brute conversion, recompile, and start fixing errors.

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

Sure.  Syntax variation should be managed by the module system,
though.  The argument goes something like, you can use whatever syntax
you want, as long as you warn me, and make sure I don't have to worry
about your syntactic extensions in the other code I'm running.  Let's
not create chaos.


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

This is a more serious problem.  I'm not sure how we'd resolve it.  We
might simply configure Guile without the threading support for Emacs.

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

Two frogs.