From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp and Guile Date: 24 Jul 2002 23:05:58 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207200035.g6K0ZAb27891@aztec.santafe.edu> <200207212015.g6LKF4c00874@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1027548808 5240 127.0.0.1 (24 Jul 2002 22:13:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2002 22:13:28 +0000 (UTC) Cc: raeburn@raeburn.org, emacs-devel@gnu.org, mvo@zagadka.ping.de Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17XUNq-0001MP-00 for ; Thu, 25 Jul 2002 00:13:26 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XUcq-0008P6-00 for ; Thu, 25 Jul 2002 00:28:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XUNs-00025W-00; Wed, 24 Jul 2002 18:13:28 -0400 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XUNM-00023y-00; Wed, 24 Jul 2002 18:12:56 -0400 Original-Received: from portalet.ossau.uklinux.net (ppp-0-181.lond-b-3.access.uk.tiscali.com [80.40.12.181]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g6OMClC13750; Wed, 24 Jul 2002 23:12:47 +0100 Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (laruns.ossau.uklinux.net [192.168.1.3]) by portalet.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 3A2471702; Wed, 24 Jul 2002 23:12:16 +0000 (GMT) Original-To: rms@gnu.org Original-Lines: 62 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6017 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6017 --=-=-= >>>>> "Richard" == Richard Stallman writes: I think that 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. Richard> What precisely is "a preprocessed version"? What I think Richard> we should do is modify the code in Emacs so that it works Richard> with Scheme. What you suggest would be ideal. I only talked about a "preprocessed version" because I was assuming that it might not be feasible to start modifying the primary Emacs codebase immediately. If this assumption is wrong, so much the better. (Would you agree with this, Ken?) Unless this picture changes, I don't plan to do any further significant work on the prototype translator. Richard> Putting aside the issue of the Emacs primitives, which we Richard> are going to handle with C code and should not be Richard> implemented in Scheme, does it need any more work? Not Richard> counting those primitives, are there Emacs Lisp features Richard> it does not handle? Or is it adequate as it stands? (If Richard> so, why call it a "prototype"? Why not call it Richard> "finished"?) 1. The Guile reader doesn't directly handle all Elisp syntax -- e.g. [ ] for vectors and ? for character/integers. The translator retrofixes some of these discrepancies -- e.g. it turns (what it sees as) symbols for the obvious alphabet characters (?a, ?b etc.) into Guile integers -- but not all of them. 2. The representation of Elisp variables doesn't allow for buffer- and frame-local variables. 3. There's no byte code interpreter. 4. There are special forms that I haven't implemented (e.g. condition-case) and several data types (e.g. buffers, char tables); but these are all really in the same category as primitives, so no big deal. It's adequate as it stands for the programmer who wants to write general purpose code using (mostly) Emacs Lisp syntax and language constructs. (For an example, see the attached file, which is included in Guile CVS for this purpose.) It's not adequate for the programmer who wants easily to build an editor application by taking advantage of a large set of relevant primitives and data types. If we assume that primitives, data types, special forms, the reader and the byte code interpreter are all dealt with by using the Emacs C code, I think the only design issue remaining is the representation of Elisp variables so that buffer- and frame-local values are supported. Does this sufficiently answer your questions? Please let me know if not. Neil --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=example.el Content-Description: Example of Elisp code that translator can handle (defun html-page (title &rest contents) (concat "\n" "\n" "" title "\n" "\n" "\n" (apply 'concat contents) "\n" "\n")) (defmacro time (repeat-count &rest body) `(let ((count ,repeat-count) (beg (current-time)) end) (while (> count 0) (setq count (- count 1)) ,@body) (setq end (current-time)) (+ (* 1000000.0 (+ (* 65536.0 (- (car end) (car beg))) (- (cadr end) (cadr beg)))) (* 1.0 (- (caddr end) (caddr beg)))))) ;Non-scientific performance measurements (Guile measurements are with ;`guile -q --no-debug'): ; ;(time 100000 (+ 3 4)) ; => 225,071 (Emacs) 4,000,000 (Guile) ;(time 100000 (lambda () 1)) ; => 2,410,456 (Emacs) 4,000,000 (Guile) ;(time 100000 (apply 'concat (mapcar (lambda (s) (concat s "." s)) '("a" "b" "c" "d")))) ; => 10,185,792 (Emacs) 136,000,000 (Guile) ;(defun sc (s) (concat s "." s)) ;(time 100000 (apply 'concat (mapcar 'sc '("a" "b" "c" "d")))) ; => 7,870,055 (Emacs) 26,700,000 (Guile) ; ;Sadly, it looks like the translator's performance sucks quite badly ;when compared with Emacs. But the translator is still very new, so ;there's probably plenty of room of improvement. --=-=-=--