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: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much) Date: Tue, 16 Jul 2002 22:58:13 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020704135240.4CBB.LEKTU@terra.es> <20020704164911.4CC1.LEKTU@terra.es> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1026874782 21227 127.0.0.1 (17 Jul 2002 02:59:42 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Jul 2002 02:59:42 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Uf2S-0005WG-00 for ; Wed, 17 Jul 2002 04:59:40 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17UfDg-0000SK-00 for ; Wed, 17 Jul 2002 05:11:16 +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 17Uf29-0005cI-00; Tue, 16 Jul 2002 22:59:21 -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 17Uf16-0005bM-00 for ; Tue, 16 Jul 2002 22:58:16 -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 g6H2wEf28084; Tue, 16 Jul 2002 22:58:14 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17Uf13-0007Hn-00; Tue, 16 Jul 2002 22:58:13 -0400 Original-To: emacs-devel@gnu.org In-Reply-To: <20020704164911.4CC1.LEKTU@terra.es> (Juanma Barranquero's message of "Thu, 04 Jul 2002 17:20:37 +0200") Original-Lines: 80 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.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:5807 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5807 Juanma Barranquero writes: > Ken Raeburn has a page on Guile-based Emacs (http://www.mit.edu/~raeburn/guilemacs/), > but it was last updated on 1999-07-07. Ken is subscribed to this list, > so I suppose he can comment on it. Yeah, I was just looking today at how old that page is.... Yes, I've been working on it slowly and quietly, as my free time allows. I'm working on it because it interests me, I'd like more opportunities to work with Scheme, I'd like to encourage others to work with Scheme, I think it would get Guile more attention (including its deficiencies in some areas, which hopefully would be readily identified with a huge application like Emacs and addressed), and I really want Simon to write those Gnus patches :-). How threads at the Scheme level might translate up to the UI, though, I have no idea. The first batch of work I did, which resulted in the state described on that web page, caused a fairly large and painful divergence, and keeping up with new stuff being added to Emacs proved to be a big time sink. So I stopped that work, and started a different approach, namely making some of the Lisp internals in the main FSF sources easier to isolate and replace. Hence the ENABLE_CHECKING, HIDE_LISP_IMPLEMENTATION, and other changes to add all sorts of compile-time and run-time checks, and the associated (functionally invisible, I hope) transformations I've been applying to various patterns throughout the sources to make more use of lisp.h macros. (BTW, I've got a patch that adds configures option to turn on ENABLE_CHECKING, or just the use of a union for Lisp_Object. Should I check it in? I've noticed one or two people have been checking in fixes for Lisp_Object/int mixups, for which I'm grateful, but I'd like to encourage more of that checking as people write the code in the first place.) At this point, int, float and cons values, and to a lesser degree strings, should be easy to rip out and reimplement. Converting other types to Guile's SCM type would be trickier because of a difference in type handling. Guile's C-level type extension system involves allocating Scheme objects which have some application type information and a pointer to the application data. In the current Emacs system, on the other hand, most of the type and pointer information is all in the Lisp_Object value, and the "==" comparisons require that the handle value be unique; you could call XSETBUFFER on a Lisp_String pointer and it wouldn't complain. So, should XSETBUFFER for Guile create one of these Scheme objects, or should it use one allocated earlier? My approach last time around was to add a SCM field to most of the "interesting" data types (symbol, misc, and vectorlike), fill it in when the object was created, and make XSETFOO just copy the value out. Rather crude, and wasteful of storage space, but it got the job done, and it minimized the intrusion in random Emacs code and kept it running with both object representations. I want to try eliminating more of the XSETFOO calls outside of object creation, in places where for example a simple assignment will do instead. But if I can't get most of them, I may have to use that same approach again. Since with the string macro stuff I've been changing in the last few days, I've nearly reached the point I had in my old development tree with regard to isolating those types I thought I could easily replace. (I was starting to work on strings but hadn't finished them. Vectors would be easy except for the bits of code that group them with the "vectorlike" types like buffers.) So I'm thinking about starting a branch soon and starting on some actual Guile code again. Once the branch is made, it should be much, much easier to get other people involved. Smooth interaction between the languages will need a lot more time, but an Emacs that uses the Guile storage system and can communicate with Scheme code, even if only by passing a few simple object types, is certainly doable; I had a proof-of-concept implementation up and limping long ago, but not remotely ready to be evaluated in terms of memory use, performance, etc. So, that's roughly what the current status is of my work.... Ken