From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp and Guile Date: Thu, 25 Jul 2002 00:22:58 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207200035.g6K0ZAb27891@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027571059 14109 127.0.0.1 (25 Jul 2002 04:24:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 25 Jul 2002 04:24:19 +0000 (UTC) Cc: rms@gnu.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 17XaAk-0003fS-00 for ; Thu, 25 Jul 2002 06:24:18 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XaPp-0000OO-00 for ; Thu, 25 Jul 2002 06:39:53 +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 17XaAt-0007Tg-00; Thu, 25 Jul 2002 00:24:27 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17Xa9Z-00076y-00; Thu, 25 Jul 2002 00:23:05 -0400 Original-Received: from kal-el.raeburn.org ([2002:d03b:b25a:1:201:2ff:fe23:e26d]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g6P4Mwf18107; Thu, 25 Jul 2002 00:22:58 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17Xa9S-0005Jm-00; Thu, 25 Jul 2002 00:22:58 -0400 Original-To: Neil Jerram In-Reply-To: (Neil Jerram's message of "20 Jul 2002 09:37:50 +0100") Original-Lines: 84 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.3.50 (i686-pc-linux-gnu) 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:6025 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6025 Neil Jerram writes: > - as a guide to the Guile Emacs project on how to interface to the > Elisp support in libguile (notably, usage of `@fop' and `@bind') So, why were @fop and @bind needed in libguile anyways? I was never clear on that. Is it for performance, or is Scheme not up to the task? > - 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. I wonder if it's the best choice. I don't think encouraging people to support translation by starting with writing more C code for libguile is wise; we'll wind up with a libguile with random primitives for supporting translated elisp and perl and tcl and python and.... Personally, I'd rather see that support in Scheme modules. That issue aside, yes, I think we definitely need work in this area. Probably another language or two as well. Real, useful languages; inventing another programming language so that we have another translator doesn't do us much good if no one uses that language. Well, that's the way it used to be. I've been focussed enough on Emacs in what free time I've had lately that I haven't even been following the Guile lists, just filing them away for later. If there are other real translators available now, then "yay!" :-) Neil Jerram writes: >>>>>> "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?) I don't think I'd use the term "preprocessed", but I suppose you could look at it that way. I haven't looked at how easy or hard it'll be to make Emacs C DEFUNs produce SCM primitive procedures. If it's easy, great. If it's hard, and we don't want to break the existing Lisp representations right away, we could look for a simple, regular substitution that could be done on the C code, or write Scheme wrappers that invoke a "call this Lisp function" Scheme primitive procedure. One of my concerns in that area is with mixing Lisp dynamic bindings and Guile thread support. If we want multi-threaded Lisp, do we pass around some sort of environment pointer, or call thread-aware routines to fetch current environment info? Neil, does your code try to support multi-threaded Lisp? > 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. Keeping the Elisp reader may be simplest. I vaguely recall concluding that cases could be constructed where the Guile reader wouldn't distinguish things in some cases where Elisp would, but I don't remember the details. I think it had to do with character or number data, or maybe "?0" type constructs. > 2. The representation of Elisp variables doesn't allow for buffer- and > frame-local variables. Still an open issue in my book too. > 3. There's no byte code interpreter. Translating to Scheme (or Guile byte codes) is another possibility. Ken