Re: emacs with guile instead of elisp

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

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

Well, I guess what I was asking is, can guile's reader handle elisp?
Just the part that slurps in sexps... clearly the part that maps
symbols to variables (values?) will have to be written, and a standard
library of functions like let, cafr, and what-not will need to be
written.  This is in contrast with, say CTAX, which has a custom
reader for reading CTAX expressions (into lists).  Then those lists
are translated into something guile can execute (incrementally and
lazily, I believe).  Right now, the generic lexer and parser are very
slow.  (Fifteen minutes to compute the parse table; this has to be
done every guile session). 

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

<shudder> A parser for Tcl shouldn't be too horrible, although Tcl's
quoting rules are a little complex.

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

Is somebody working on one?  It seems like cloning scheme48's would
be a Good Idea.  It would also be a good place to introduce separate
compilation. 

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

I think we may always want to undump just before execution --- as well
as separate compilation.  But regardless, it is important that it be
possible to store precomputed results in an easy-to-load form.  And
unfortunately, this form probably includes smobs (eg, compiled
regexps). 

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

Hmm.  I'm not sure I understand how best to integrate new syntaxes
with the module system.  Right now, the way to do it is to have a
scheme module which just does (eg.)  (eval (ctax-read "file")).  But
the ctax translator does use the module system to keep symbols
properly placed.  It's important that all symbols be on an equal
footing regardless of language, though. 

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

Emacs could really use threading.  

; > So, how much work/what effort would be involved in this?
; 
; Two frogs.

... yeah. 

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