Re: emacs with guile instead of elisp

[Jim Blandy <jimb@red-bean.com>]

> Well, I guess what I was asking is, can guile's reader handle elisp?
> Just the part that slurps in sexps...

No.  And it shouldn't.  Emacs Lisp's s-expression syntax is similar in
the barest essentials, but very different in many details.  Trying to
get a single reader to handle both of them would just annoy both the
lispers and the schemers.

For example:

[1 2 3]
   Guile: a symbol [1, the number 2, and a symbol 3]
   Emacs Lisp: a vector
#("abc" 0 1 (color red) 1 3 nil)
   Guile: a vector
   Emacs Lisp:a string with text properties

I don't even want to think about floating-point stuff, variations in
symbol character sets, oddities used in Emacs Lisp bytecode files
(which are read using the standard Emacs Lisp reader)...

We'll write a new reader, probably borrowing code from Emacs Lisp's
reader.  We'll probably not use the generic `lang' stuff; it's
beautiful, and impractical.


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

I don't think they're too bad.  They're probably simpler to implement
than doing quasiquote right.

I don't know anything about the internals of Perl, but perhaps one
could could use the existing parser as the front end for a Perl->Guile
translator.  Given what I know of Perl's syntax, I'd guess that'd be
more reliable than writing one afresh.


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

There are a bunch of issues involved here.  In speeding up the module
system, we can also make it more versatile, and add hooks to solve a
bunch of problems (including a graceful way to handle syntax
variations, and translators for other languages).

I'm hoping to work on these things soon.  They won't be done in 1.3.


> 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, but my point was that we don't need to choose between separate
compilation and undumping; the right language-level constructs will
support both of them cleanly.  I think.  :)


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

Yes; that thought runs through my head every day while I wait for Gnus
to incorporate my new mail.  But that doesn't mean we have to solve
that problem when we integrate Guile.  There are a lot of issues in
Emacs to take care of first.  We just want to make sure Guile isn't
another source of problems.


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

Not only did I not have an answer, I couldn't even think of what units
the answer would be in...  :)