Re: ELisp?

[Ken Raeburn <raeburn@raeburn.org>]

On Oct 9, 2011, at 15:22, Noah Lavine wrote:
> 
> One question I have is, how much of Emacs' C code can Guile use right
> now? I guess Ken Raeburn's patches are the ones that address that, but
> I don't know what is left to do.

With the stuff I've done, not much execution happens with Guile's engine, and I'm not sure Guile can actually invoke anything from the Elisp side directly.  I did add an "evaluate as Lisp" Scheme function and vice versa at one point (I *think* it was even in the public repository), but it's a pretty minimal level of support.  It was enough to throw together a simple and crude "interactive Guile mode" similar to the interactive Emacs Lisp mode -- ielm -- that lets you type and evaluate expressions in-process in a buffer.  So when you hit return, Emacs Lisp code looked at the s-expression and passed it off to be evaluated as Scheme, though if I recall correctly, strings were passed back and forth between the two environments because symbols are (were) still too different.

> (I also have the same question about ELisp - what of the language is
> left to implement? Is it just adding more builtins?)

In addition to "what of the language is left to implement", I'd suggest that the work remaining should include:

* conformance tests
  ** lots of the Emacs-specific extensions like buffer-local variables and defaults, int-only variables, aliases, etc
  ** interactions between them (e.g., let-bindings plus local variables when switching buffers)
  ** stack overflow protection
  ** out-of-memory handling
  ** error/signal trapping
  ** timeouts, event processing
  ** errors storing to special kinds of variables
  ** weak hashes (make sure excess references aren't kept around due to handling of symbol function slots, object properties, etc, and that GC doesn't take things it shouldn't)
  ** defadvice
  ** debugger? debug-on-entry? debug-on-quit?
* performance tests
  ** high-level - e.g., byte-compile, hanoi, font-lock, hairy regexp search and replace
  ** specific functionality - global/dynamic/local bindings, symbol or text properties
  ** startup time
  ** both speed and memory use; include tests on memory-limited configurations
  ** multiple architectures
     *** including at least one without Scheme->native compilation
  ** multiple OSes
     *** GNU/Linux
     *** Windows (preferably native, not mingw/cygwin)
     *** at least one non-GNU-libc one
     *** the more the merrier
* tests of Lisp/Scheme interactions
  ** expected nil/#f/()/#t/t handling in both Lisp and Scheme
  ** symbol value vs symbol function slot
  ** inter-language calls
  ** interactions of Lisp features with Guile threads (if Emacs Lisp doesn't get threads first)
     *** buffer-local or dynamic bindings and thread creation
     *** is the current buffer a per-thread concept?

Those would be a lot more convincing than "I typed in a bunch of Lisp commands and read my email, and it all looked okay", though of course we want to try those too.  This is a major and fundamental change we're proposing for Emacs, and not all of the Emacs developers are convinced it's a good thing.  Having tests like these (and a lot more for the full Guile-Emacs implementation) may help convince people that we've done our homework.

We don't necessarily have to look better on all the performance numbers.  Though, if we don't look better on most of them, maybe it's a sign that we've got more work to do first.


> A branch on Savannah sounds like a really good idea though. Then at
> least there would be a central thing for people to look at and hack
> on, and more people might get involved. Right now I suspect that most
> people don't know what's happening or where to look. If you set up a
> branch, I for one would love to check it out and perhaps contribute
> some patches. Do you need permission from the Emacs maintainers to do
> that, or anything else?

If there's a specific plan for moving forward, and someone in particular planning to work on it and coordinate, a branch on savannah may be a good idea.  The plan has got to cover dealing with changes happening in the main Emacs development in the meantime (frequent merges or rare, big merges?), stuff like that.  If it's just, "I'll hack on it for a few months and see how it goes, and then see if someone else wants to take over", I'm not sure it'd be worthwhile.

Wherever the work gets done, it's important for everyone to have signed assignment or disclaimer paperwork covering both Emacs and Guile, unless they're going to be working very clearly on just one side or the other.

Ken