From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.lisp.guile.devel Subject: Re: ELisp? Date: Fri, 11 Nov 2011 10:46:38 +0100 Message-ID: References: <8384F5A2-FD71-43D0-8497-59A542D0B6A5@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1321004831 10612 80.91.229.12 (11 Nov 2011 09:47:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2011 09:47:11 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 11 10:47:07 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ROnhS-0008RC-2J for guile-devel@m.gmane.org; Fri, 11 Nov 2011 10:47:06 +0100 Original-Received: from localhost ([::1]:59214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROnhR-0003Hm-Kl for guile-devel@m.gmane.org; Fri, 11 Nov 2011 04:47:05 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:32889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROnhL-0003Hd-Sm for guile-devel@gnu.org; Fri, 11 Nov 2011 04:47:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROnhH-0002yi-ML for guile-devel@gnu.org; Fri, 11 Nov 2011 04:46:59 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:49486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROnhH-0002ye-8p for guile-devel@gnu.org; Fri, 11 Nov 2011 04:46:55 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ROnhE-0008JR-DV for guile-devel@gnu.org; Fri, 11 Nov 2011 10:46:52 +0100 Original-Received: from 88.80.164.166 ([88.80.164.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Nov 2011 10:46:52 +0100 Original-Received: from joakim by 88.80.164.166 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Nov 2011 10:46:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 90 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 88.80.164.166 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) Cancel-Lock: sha1:AE70wS/l8SKMr5nUApwB9wOJ4P4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12883 Archived-At: Ken Raeburn writes: > 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. Where is your public repository? I would be interested to have a look. A String interface is an okay start. > >> (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. Okay, so a Savannah branch can wait. Anyway, I think a successful approach must be incremental. Elisp and Guile can co-exist for the time being. As a concrete example, one could use guiles libffi integration to offer the same feature to Emacs. I could personally use it in my xwidgets emacs branch to call dynamically into webkit rather than having to make a c wrapper for each and every function. So, mainline Emacs would offer optional core guile integration for advanced features. That would be no worse than embedding guile in any other application and would offer benefits in its own right. > 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. I have papers for Emacs at least, and no issue with signing more papers. > > Ken > -- Joakim Verona