From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: guile and emacs and elisp, oh my! Date: Sat, 24 Apr 2010 17:02:10 -0700 Message-ID: <1272153730.8979.71.camel@dell-desktop.example.com> References: <1271988038.5907.7.camel@dell-desktop.example.com> <1272062597.6107.29.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1272153753 29275 80.91.229.12 (25 Apr 2010 00:02:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 25 Apr 2010 00:02:33 +0000 (UTC) Cc: Tom Tromey , emacs-devel@gnu.org To: Andy Wingo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 25 02:02:30 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O5pIp-0007s3-L1 for ged-emacs-devel@m.gmane.org; Sun, 25 Apr 2010 02:02:28 +0200 Original-Received: from localhost ([127.0.0.1]:46017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5pIo-0007QY-VA for ged-emacs-devel@m.gmane.org; Sat, 24 Apr 2010 20:02:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5pIh-0007QJ-CG for emacs-devel@gnu.org; Sat, 24 Apr 2010 20:02:19 -0400 Original-Received: from [140.186.70.92] (port=54196 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5pIe-0007OJ-CX for emacs-devel@gnu.org; Sat, 24 Apr 2010 20:02:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5pIb-0000CG-Ug for emacs-devel@gnu.org; Sat, 24 Apr 2010 20:02:16 -0400 Original-Received: from smtp181.iad.emailsrvr.com ([207.97.245.181]:33891) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5pIb-0000CA-QN for emacs-devel@gnu.org; Sat, 24 Apr 2010 20:02:13 -0400 Original-Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 446A51B4012; Sat, 24 Apr 2010 20:02:13 -0400 (EDT) Original-Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 5BE591B4006; Sat, 24 Apr 2010 20:02:12 -0400 (EDT) In-Reply-To: X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124184 Archived-At: On Sat, 2010-04-24 at 13:05 +0200, Andy Wingo wrote: > Hi Tom, Hello. > Thanks for your mail, it brought up some things I hadn't thought about. Glad to help. > On Sat 24 Apr 2010 00:43, Thomas Lord writes: > > Sure, Schemers ought to be encouraged to write > > "(null? x)" rather than "(eq? x '())" but ... > > what about "(eq? x y)"? > To me, `(null? x)' checks nullity. `(eq? x '())' is ambiguous -- it > could be a check for nullity, or it could be a check for identity. `(eq? > x y)' to me is unambiguous though, it is a check for identity. > I would be interested to know if you had a case in mind in which the > introduction of nil to Scheme let to incorrect results via `(eq? x y)', > beyond those documented in Nil.html. An example is easier with elisp EQUAL and Scheme EQUAL?: Because they give different results: (equal? #nil #f) => #f (equal nil f) => t the two languages can not even reliably agree when two keys in an equality-based association are the same. > > More damingly, perhaps, what distinction does > > Guile plan between the Scheme symbol, "'nil", and > > Emacs the Emacs lisp symbol, "nil"? Do emacs > > lisp and Guile not even agree on what is and what > > is not a symbol? > Irritating! I did not even realize that nil was a symbol. (symbolp nil) => t (symbolp t) => t Per old lisp tradition, they are symbols bound permanently to themselves: (symbol-value nil) => nil (symbol-value t) => t (let ((t 3)) t) => ERROR: attempt to set a constant symbol > Given that there appear to be few Elisp primitives that operate on > symbols, I imagine the way this will go will be for nil to not be a > symbol to Scheme, but we'll add some shims to elisp to have it be a > symbol, and have the elisp reader read 'nil as nil. There are only about > 50 instances of 'nil in the emacs source, and some of them are ''nil, so > hopefully this will not cause too much of a problem. And I guess you will have to do the same for #t? Suppose that Scheme's STRING->SYMBOL is made available (directly or indirectly) to the Emacs lisp side. Then: ,L elisp ;; for some symbol bound to sym: ;; (eq sym (string->symbol (symbol-name sym))) => t in all cases where sym is not nil or t => nil otherwise If Emacs lisp's INTERN is made available directly or indirectly to Scheme: (eq? sym (intern (symbol->string sym))) => #t in all cases where sym is not 'nil or 't => #f otherwise I find it hard to think through what code that might break or what kinds of things it will make hard to write. I find strange, random exceptions to simple rules hard to think through in general. That's why I describe the result here as the kind of programming environment that nobody would ever design on purpose - an environment that seems to have features whose sole (apparent) purpose is to make programming harder. Is upwards compatibility with elisp really worth that much? > To my (naively optimistic?) tastes, we're not at chaos yet; but this is > certainly a step in that direction. Back in yesteryear, I was pretty optimistic about joining Scheme and Emacs lisp, too. Things were different, back then. R5 was not yet released. R4RS and IEEE were the latest standards and were the *first* to require that Scheme '() not be a false value. Indeed, R3RS *required* '() to be false and stated: (eqv? '() #f) => *unspecified* So, at first, we thought to just diverge from that newfangled R4RS noise and Guile would be a Scheme in which: (eq? '() #f) => #t Additionally, all symbols would have a dynamic binding slot (in effect, every symbol would be a "fluid" in today's Guile terminology). I don't recall that we had clearly thought through the problem of '() (elisp's nil) not being a symbol. Pressure grew to distinguish '() and #f and at some point, a proposal for #nil (very much like the one you have now) was put forward. At first I thought that might work but it nagged at me. The more I thought about it, the less I believed that it or any other "solution" could work. > > And: since Emacs lisp and Guile can't agree about > > equality (whichever flavor) - how do I write a > > hash table library useful to both environments? > Scheme will probably get some new operators out of all of this: nil-car, > nil-cdr, nil-equal?, nil-hash, nil-assoc, etc. By default, a hash table > implemented in Scheme would treat nil and '() as distinct, though you > could implement one with nil-hash and nil-assoc and you get an > elisp-style hash table. Elisp hash tables use Elisp hash and assoc, > which are bound to nil-hash and nil-assoc or their equivalents. So much for re-using code written for other Scheme implementations. And, again: Scheme is already a touch suspect for having three distinct equality predicates instead of the more customary two. Now you propose to add a fourth. It's also unfortunate that this will make a mess out of using the FFI. When an extension function written in C uses an equality predicate or a checks to see if something is a symbol: what should be its policy - Scheme rules or Emacs lisp rules or some kind of dynamically configrable option? > > If, absent the historic liabilities, someone proposed > > a programming environment with multiple syntaxes, sure, > > but all sharing a common data representation - with > > (), #f, and Emacs lisp nil .... wouldn't you think they > > were kind of insane? The multiple syntaxes part - fine. > > But the triad of (), #f, and nil? It would seem, in my view, > > to be a (mis-)feature designed mainly to make programming > > in that environment harder. > I am inclined to agree, though I would probably state things > differently: the Elisp code that is out there is liability, yes, but > wealth also. Perhaps. But that "wealth" can be preserved in other ways. For example, by writing tools that assist in the semi-manual translation of Emacs lisp to Scheme. > As you note, we're always making these economic decisions, and with > regards to unknown (and often unquantifiable) costs and benefits -- well > you never really know until you step into that unknown, right? (And the > reasons that lead one to make those steps often go by slippery names > like "faith" or "instinct" or such things.) Sure. And I'm not one to stop you from following your dreams. I think that there are some objective things to contemplate: Disjointness of types, truth and falsity, uniformly represented lists, and universal equivalence and structural equivalence predicates are *central* to many (perhaps most) idioms of lisp programming, in every dialect, for as long as there has been lisp. Those are the basic aspects of values in general. >>From first principles you can correctly deduce that Emacs lisp and Scheme must always disagree about disjointedness, the representation of lists, equivalence, and structural equivalence. It is trivial to get them to agree about falsity by introducing #nil, but doing so makes the disjointedness, list representation, and equivalence predicates even more problematic. It's a "now you have two problems" kind of situation. >>From historic reality you can also see that the decision to add #nil *greatly limits the prospects for Guile and Emacs in the future*. In particular, there will be a long-term barrier on re-using any third party Scheme code, FFI-extension to Scheme, or new and better Scheme implementation. The proposal here is to exit the isolated and lonely world of Emacs Lisp and start afresh in an isolated and lonely world of Guile+Emacs Lisp. You can have your dreams and, heck, you might be right. After all, the problems of three little lisp values don't amount to a hill of beans in this crazy world. But as for me, I'm not telling you get on that plane. I don't think the Scheme Underground resistance movement benefits. And I'm pretty sure you're not really in love with the whole plan. If you take that plane, if you ask me, one day you'll regret it. Maybe not today, maybe not tomorrow, but soon and for the rest of your life. > Anyway, rambling here at the end. It's good to talk it through. > I respect your desire for a new lovely > Scheme Emacs; but I think I'm going to try for a future world that > includes Elisp and Elisp programmers. Maybe over time it all stays in > Elisp; that's fine. Maybe people find they like Scheme better, and > incrementally rewrite things in that language. That's cool too, and > personally I hope things go that way. But we'll see! I suppose we shall. -t > Happy hacking, > > Andy