From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: ELisp? Date: Tue, 11 Oct 2011 06:12:34 -0400 Message-ID: <8384F5A2-FD71-43D0-8497-59A542D0B6A5@raeburn.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1318327975 19866 80.91.229.12 (11 Oct 2011 10:12:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2011 10:12:55 +0000 (UTC) Cc: guile-devel@gnu.org, joakim@verona.se To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 11 12:12:51 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 1RDZKM-0005tS-Cl for guile-devel@m.gmane.org; Tue, 11 Oct 2011 12:12:50 +0200 Original-Received: from localhost ([::1]:46818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDZKL-0002h7-Qe for guile-devel@m.gmane.org; Tue, 11 Oct 2011 06:12:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDZKH-0002gi-EO for guile-devel@gnu.org; Tue, 11 Oct 2011 06:12:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDZKA-0002Ro-7Y for guile-devel@gnu.org; Tue, 11 Oct 2011 06:12:45 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:43752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDZKA-0002Ra-4L for guile-devel@gnu.org; Tue, 11 Oct 2011 06:12:38 -0400 Original-Received: by vcbfo14 with SMTP id fo14so6588058vcb.0 for ; Tue, 11 Oct 2011 03:12:36 -0700 (PDT) Original-Received: by 10.52.182.198 with SMTP id eg6mr17839803vdc.16.1318327956695; Tue, 11 Oct 2011 03:12:36 -0700 (PDT) Original-Received: from [10.0.0.158] (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id h15sm6823368vdg.7.2011.10.11.03.12.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 03:12:35 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 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:12834 Archived-At: On Oct 9, 2011, at 15:22, Noah Lavine wrote: >=20 > 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=