From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9405 invoked by alias); 8 Feb 2002 11:53:39 -0000 Mailing-List: contact guile-emacs-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-emacs-owner@sources.redhat.com Received: (qmail 9337 invoked from network); 8 Feb 2002 11:53:35 -0000 Received: from unknown (HELO s1.uklinux.net) (80.84.72.21) by sources.redhat.com with SMTP; 8 Feb 2002 11:53:35 -0000 Received: from portalet.ossau.uklinux.net (IDENT:root@ppp-1b-36.3com.telinco.net [212.159.129.36]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g18BrUq29306; Fri, 8 Feb 2002 11:53:30 GMT Envelope-To: guile-emacs@sources.redhat.com Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (neil@laruns.ossau.uklinux.net [192.168.1.3]) by portalet.ossau.uklinux.net (8.9.3/8.8.7) with ESMTP id LAA23671; Fri, 8 Feb 2002 11:53:21 GMT To: Guile Development CC: guile-emacs@sources.redhat.com Subject: Elisp translator work finished (for now) From: Neil Jerram Date: Fri, 08 Feb 2002 03:53:00 -0000 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-q1/txt/msg00013.txt.bz2 I've now finished my currently planned work on the Emacs Lisp translator in guile-core CVS. It works well enough for experimentation and playing around with -- see the README file for details of what it _can_ do -- but has two serious restrictions: - Most Emacs Lisp primitives are not yet implemented. In particular, there are no buffer-related primitives. - Performance compares badly with Emacs. Using a handful of completely unscientific tests, I found that Guile was between 2 and 20 times slower than Emacs. (See the comment in lang/elisp/example.el for details of tests and results.) Interestingly, both these restrictions point in the same direction: the way forward is to define the primitives by compiling a preprocessed version of the Emacs source code, not by trying to implement them in Scheme. (Which, of course, is what Ken Raeburn's project is already trying to do.) Given this conclusion, I expect that most of the translator's Scheme code will eventually become obsolete, replaced by bits of Emacs C code. Until then, though, it should have a role: - as a guide to the Guile Emacs project on how to interface to the Elisp support in libguile (notably, usage of `@fop' and `@bind') - as a proof of concept and fun thing to experiment with - as a working translator that could help us develop our picture of how we want to integrate translator usage in general with the rest of Guile. Comments are (of course) welcome. Best regards, Neil