From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: guile and emacs and elisp, oh my! Date: Tue, 20 Apr 2010 16:36:34 -0600 Message-ID: References: Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1271806861 1850 80.91.229.12 (20 Apr 2010 23:41:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 20 Apr 2010 23:41:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Wingo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 21 01:40:54 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 1O4N3m-0007pd-FX for ged-emacs-devel@m.gmane.org; Wed, 21 Apr 2010 01:40:54 +0200 Original-Received: from localhost ([127.0.0.1]:51452 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Mmi-0003nV-45 for ged-emacs-devel@m.gmane.org; Tue, 20 Apr 2010 19:23:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4M3u-00074u-ER for emacs-devel@gnu.org; Tue, 20 Apr 2010 18:36:58 -0400 Original-Received: from [140.186.70.92] (port=43597 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4M3c-0006u8-VR for emacs-devel@gnu.org; Tue, 20 Apr 2010 18:36:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4M3a-0001qe-6v for emacs-devel@gnu.org; Tue, 20 Apr 2010 18:36:40 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:54760) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4M3Z-0001qT-Rx for emacs-devel@gnu.org; Tue, 20 Apr 2010 18:36:38 -0400 Original-Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3KMaaaW032236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Apr 2010 18:36:37 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3KMaaLI013048; Tue, 20 Apr 2010 18:36:36 -0400 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o3KMaZ9Z019871; Tue, 20 Apr 2010 18:36:35 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id F146037979C; Tue, 20 Apr 2010 16:36:34 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Andy Wingo's message of "Wed, 14 Apr 2010 22:18:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:123943 Archived-At: Andy> My name is Andy, and together with Ludovic Court=C3=A8s I co-maintain= Guile. Hi. Thanks for writing this. I'm somewhat hesitant to write this response, since although I'm a longtime Emacs-lover and random contributor, I'm not an Emacs developer by any stretch. So it isn't clear that I have standing to try to push a particular big agenda. Nevertheless, I care a lot about Emacs and I found that my view on this topic has not been well-represented. Andy> Guile can implement Emacs Lisp better than Emacs can. Andy> No one will notice! Except that after a switch, Emacs would be faster, Andy> more powerful, and have the ability to access all of Guile's faciliti= es Andy> -- the Scheme language, other languages implemented for Guile Andy> (Javascript, Lua, ...), a proper ffi, dynamically loadable libraries,= a Andy> module system, the numeric tower (rationals, bignums, etc), Guile's Andy> existing libraries, delimited continuations (!), fast bytevector acce= ss, Andy> native threads, etc. >From my perspective, many of these are either not interesting, or are outright misfeatures. Let me explain. First, people have often discussed the desirability of one runtime to rule them all. This has even been attempted -- Gnome floated a proposal, there is Parrot, even the JVM and .NET are getting in on it. I think, contrariwise, that not only is this not desirable, it is actively bad. I think it is beneficial to a program like Emacs to have a single extension language. A single language makes both reuse and debugging simpler. Multiple languages equals chaos. Furthermore, I think that secondary implementations of popular languages (why even consider the unpopular ones?) are destined to always remain second-class citizens. There is plenty of evidence to support both these assertions: the wretched state of Gnome scripting (brought on, IMO, by its tower-of-babel approach), and the lessons of Jython, Iron Python, et al. For the other points: * FFI, and dynamically loadable libraries. This feature has come up and been rejected several times for Emacs. Anyhow, as with all of these features, we don't need Guile to implement it -- and in fact that is an extremely roundabout way to add a simple feature. * A module system. I've seen this idea explicitly rejected by RMS. * The numeric tower. Ok, this one is interesting! But switching to Guile doesn't actually push this into the one place where it is needed: buffer sizes. In fact, this is a sort of general problem with the rebase -- from what I understand, it doesn't deeply touch the bits that matter. * Continuations. If you thought threads were going to wreak havoc, wait until people call/cc from inside redisplay. * Native threads. There's an Emacs patch already. My experience with Emacs as a user and occasional developer is that elisp is fast enough for most tasks you'd actually want to write in elisp. Sure, maybe parsing could use some low-level love (something better than parse-partial-sexp), or maybe regexps could use a speedup, but even those are marginal. Even the GC doesn't seem so bad nowadays. Instead, I see three areas for improvement. 1. Platform integration. Some progress has been made here (dbus comes to mind). My pet missing feature here is notification area support, but there are others (e.g., embedding). 2. Display model. If you try to write, say, a decent presentation program in Emacs (let alone something truly complex like a browser), you quickly run into holes. 3. Blocking behavior. I run nearly everything in Emacs, and anything that blocks is at least an annoyance, and can even wreak havoc (causing an irc timeout is no fun). Emacs has decent-ish tools for handling this problem already, except for situations like Gnus -- which is why I started working on threads. So, what I would propose is that instead of putting a lot of energy into rebasing Emacs on a different VM, put that same energy into providing features that affect users. If elisp doesn't quite suit, I propose simply accepting that elisp is its own language, and not be constantly looking at Scheme or CL as the promised land: just evolve elisp in situ, say by merging lexbind or adding threads or whatever else there that is both concrete and incremental. Tom