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 and guile (Re: ehelp woes, or why I hate a module that I love so much) Date: Thu, 18 Jul 2002 15:54:43 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020704135240.4CBB.LEKTU@terra.es> <20020704164911.4CC1.LEKTU@terra.es> <200207181456.g6IEu0J25108@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 1027025637 17603 127.0.0.1 (18 Jul 2002 20:53:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 18 Jul 2002 20:53:57 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17VIHc-0004Zn-00 for ; Thu, 18 Jul 2002 22:53:56 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17VITf-0007re-00 for ; Thu, 18 Jul 2002 23:06:23 +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 17VIHX-0000LY-00; Thu, 18 Jul 2002 16:53:51 -0400 Original-Received: from delysid.gnu.org ([158.121.106.20]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17VIFJ-0008Qt-00; Thu, 18 Jul 2002 16:51:34 -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 delysid.gnu.org with esmtp (Exim 3.34 #2) id 17VHRA-00042G-00; Thu, 18 Jul 2002 15:59:44 -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 g6IJshf04040; Thu, 18 Jul 2002 15:54:43 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17VHMJ-0008Hw-00; Thu, 18 Jul 2002 15:54:43 -0400 Original-To: rms@gnu.org In-Reply-To: <200207181456.g6IEu0J25108@aztec.santafe.edu> (Richard Stallman's message of "Thu, 18 Jul 2002 08:56:00 -0600 (MDT)") Original-Lines: 87 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:5875 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5875 Richard Stallman writes: > I don't think this method makes real sense, because if an object is > going to have the scheme object header at all, we may as well use that > object header universaly throughout Emacs as the way to reference the > object. It would cost no extra storage, and it would be simpler. It would certainly be simpler, just a little slower as the object-to-pointer conversions are done multiple times, particularly when a function called frequently is changed from taking a pointer argument to taking a lisp object. I've made a few changes along those lines, and will almost certainly make more. > Why can't Guile's symbols be used as Lisp symbols? Actually, the issue is the symbol's value(s). Scheme symbols don't have separate function and value slots. Emacs Lisp symbols have a few other fields associated with them, like indirect_variable, that also don't fit the basic Scheme model. And if we separate the name from the values, there's the question of what exactly a symbol is. There are several ways to deal with this. Some involve changing Guile's symbol representation to have the extra fields. IMNSHO this is tantamount to declaring Scheme not to be up to the task of implementing Lisp, and I'm not prepared to believe that. (That Guile isn't currently up to the task, maybe; we'll find out, and Guile's Scheme implementation can be improved. That Scheme can't do it, no.) It also sets a poor example for people wanting to put other existing languages on top of Guile. Another approach would be to use Scheme symbols, but store as their values vectors containing the various fields of a Lisp symbol. Special accessor functions would be needed for Scheme code to manipulate Lisp variables, and while I don't have a problem with that, the people who want transparent interaction between the two languages probably won't like it. I guess it depends whether you view it as Lisp on top of Scheme, or the two languages working side by side. I'm inclined towards the former view, maybe only because it's easier for an implementor or designer, but I understand the temptation of the latter for such similar languages. But in that case, how do you implement Lisp's "symbolp" when looking at Scheme objects? Is a Lisp symbol a Scheme symbol that has a particular kind of object as its value? Should other Scheme symbols be treated as Lisp symbols? If a Scheme symbol has a value, what happens if you do an "fset" or "let" on it in Lisp? (Maybe that's an argument for separate namespaces for Scheme and Lisp symbols, outside of explicitly requested sharing.) Treating Lisp symbols as a new type is a third approach. (Either an opaque type, or a vector as above but also including the symbol's name.) It's what I did before, and it does sidestep a lot of these issues by simply not allowing any sort of confusion between the two symbol types, but it's not as appealing as using Scheme symbols. A related issue is the symbol name -- a Lisp symbol name is a Lisp string, with some of the associated fields ignored for matching purposes. The names themselves can have text properties: ELISP> (symbol-name 'booga-booga) #("booga-booga" 0 3 nil 3 6 (some-prop some-val) 6 11 nil) (I got this by previously interning a string with the same contents and some text properties.) An Emacs Lisp symbol's name can also be changed after interning, such that it won't be found when interning either the old name or (probably) the new name. I don't know what Scheme's specifications might say about such cases. (Much as I like Scheme, I'm hardly an expert; on subtle Scheme issues I'll readily defer to others.) I really hope no one is relying on such weird behavior, but if it needs to be maintained, that's another complication. Because I don't have all the answers, I think it's simplest to plan to treat them as separate types initially, and then merge them if and when we decide a particular approach will work well in all cases we care about, perhaps even before the actual coding starts, but perhaps not; worst case, we change a few Lisp macros to just invoke Guile macros. It's easier than starting coding on the assumption that they'll be the same, and then finding that we have to separate them. Ken