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 in Emacs Date: Wed, 14 Apr 2010 12:07:05 -0700 Message-ID: <1271272025.6576.49.camel@dell-desktop.example.com> References: <4B8147A9.7030504@gmail.com> <87wrxrr4md.fsf@gnu.org> <3vsk8ecg6a.fsf@fencepost.gnu.org> <873a0euot4.fsf@stupidchicken.com> <873a0cyv3r.fsf@lola.goethe.zz> <87aauiho3y.fsf_-_@lifelogs.com> <1271028837.6164.55.camel@dell-desktop.example.com> <1271102739.6067.38.camel@dell-desktop.example.com> <8039yz34ka.fsf@tiny.isode.net> <1271173887.6067.53.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 1271272059 13450 80.91.229.12 (14 Apr 2010 19:07:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Apr 2010 19:07:39 +0000 (UTC) Cc: "bruce.stephens@isode.com" , Christian Lynbech , "rms@gnu.org" , "emacs-devel@gnu.org" To: christian.lynbech@tieto.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 14 21:07:37 2010 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 1O27vx-00031q-38 for ged-emacs-devel@m.gmane.org; Wed, 14 Apr 2010 21:07:37 +0200 Original-Received: from localhost ([127.0.0.1]:40233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O27vo-0003V6-KW for ged-emacs-devel@m.gmane.org; Wed, 14 Apr 2010 15:07:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O27vk-0003Uv-4U for emacs-devel@gnu.org; Wed, 14 Apr 2010 15:07:20 -0400 Original-Received: from [140.186.70.92] (port=42222 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O27vd-0003To-Lb for emacs-devel@gnu.org; Wed, 14 Apr 2010 15:07:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O27vY-0004gD-5D for emacs-devel@gnu.org; Wed, 14 Apr 2010 15:07:11 -0400 Original-Received: from smtp181.iad.emailsrvr.com ([207.97.245.181]:56826) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O27vY-0004fz-1f for emacs-devel@gnu.org; Wed, 14 Apr 2010 15:07:08 -0400 Original-Received: from relay8.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 4EE14209433; Wed, 14 Apr 2010 15:07:07 -0400 (EDT) Original-Received: by relay8.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 38C2B202DFE; Wed, 14 Apr 2010 15:07:06 -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:123661 Archived-At: I really didn't mean to provoke a 20 message thread about what was, to me, just an idle thought and an interesting idea I wanted to share. So, below I'll reply to Christian and I'll also indirectly reply to some of the other messages - but unless there is someone or are some people who, right away, want to start working on a Scheme-based Emacs - there is probably not a lot to discuss. If there *is* a non-empty set of people who want to work on it, they should speak up and we can try to organize such an effort - the first step of which would be to convene elsewhere besides this mailing list. Otherwise, the whole thing is just a (to me) pretty thought that I wanted to share with others who might like to put in the back of their minds and contemplate it a bit, until perhaps someday when there is an obvious course of action to take. On Wed, 2010-04-14 at 08:45 +0200, christian.lynbech@tieto.com wrote: > I am personally mostly worried about Thomas' points about > getting scheme and emacs lisp to coexist. I just cannot > see any evolution of emacs fly in the real world if it > involves a clean cut away from the existing base > of emacs lisp libraries. How we would ever get > all developers and all users to back up such a move > is beyond me ("all" used here in the sense > of "enough to form a critical mass"). That's a legitimate concern but there are viable solutions to the problem: a) I'm *not* suggesting the idea of abandoning work on the main development line of GNU Emacs. I would expect that work to continue and to continue to use Emacs lisp. There are so many GNU Emacs users and the program generates such a large amount of good will for GNU that it seems to me very desirable to not "fix" what isn't broken. b) I don't imagine that a Scheme-centric Emacs would find itself with especially huge numbers of users in its first few years of life. I would *guess* that what would happen is that many people would try out the first release just to see what the fuss was about, that a much smaller number would stick with it, and that a slightly smaller number of those initial users would become contributing developers. My guess is based on the assumption that the first release is any good. If things went well in the first few years, then the Scheme-based Emacs might start becoming seriously popular. c) Someone - I think it was Tom Tromey - observed that Emacs Lisp is hardly something that is holding Emacs back (so why change at all?, he asks). I pretty much agree with that, at least in this sense: If the only serious difference between GNU Emacs and a new Scheme-based GNU Emacs were a change in extension language - then there would be little point in bothering. To succeed, a Scheme-based Emacs project would have to produce an Emacs with features that users really enjoy but that would be hard if not impossible to do in GNU Emacs with Emacs lisp. (In contrast, just replacing the Emacs lisp interpreter with a version of Guile that faithfully implements Emacs Lisp can succeed without needing to produce radically new features.) What kind of features might a Scheme-based Emacs offer that would be that important? Some speculation: Because Emacs Lisp support would be an explicit non-goal, everyone's favorite lisp package would have to be re-written (though, yes, often cribbing off of the Emacs Lisp version). Thus there would be opportunity (and a forcing function) to reconsider countless "little annoying details" of those packages and produce new versions with many improved details. Because a Scheme engine *should* wind up being significantly faster, and because such radical changes to the C code would be needed anyway, there is an opportunity to write more of the editor in the extension language, and less in C. In and of itself that doesn't help users. In practice it can help users by making more of Emacs much easier to modify and improve. For example (and, yes, this is a bit hand-wavy): if more of the display code were in Scheme, there is a good chance that there would be more and fancier features and "nice touches" in the display. I think that most people would agree that Scheme is a significantly more powerful language than Emacs lisp in the sense that it is easier to write more sophisticated programs in Scheme (with its closures, its fancy macro systems, and so forth). This, again, does not directly benefit users. In practice it could benefit users because in the same number of lines of code (Scheme vs. Emacs Lisp) an extension package could often provide more ambitious, fancier features. I've a few times mentioned the example SCSH (the Scheme shell) and it's a fine example to use here: a SCSH is not especially large or complicated. SCSH presents a subprocess management interface that is light years ahead of Emacs' and that would be rather painful to write in Emacs Lisp. The interface to sub-processes is again of no direct importance to users but what would benefit users are creative new applications enabled by the new interface. That is, Scheme's more powerful environment leads to subsystems like SCSH which leads to extension package developers using sub-processes more often and in fancier ways which - one would hope - leads to fancier, user-facing extension language packages. You get the idea, I hope. Scheme isn't some magic bullet that, by its mere presence, would advance Emacs into a bright new future. It is a nicer, more comfortable extension language, more standard than Emacs lisp, and affording more efficient implementations than Emacs lisp could ever hope to afford - all details that don't help users directly. The stubborn decision to start fresh and cannibalize GNU Emacs to make a Scheme-based Emacs *could* be, in addition to possibly being fun, a catalyst. By forcing the rewrite or significant modification of large subsystems, it would force a careful design review and updating - without the pressure of being upwards compatible with Emacs lisp. In that adapt / rewrite process, there is opportunity not just to go after one or two new "killer features" - but rather to go after many, many small but noticeable improvements all across the board. And if more of the editor is written in the extension language and the extension language is a more powerful language with a faster implementation - then it *should* (no guarantees) work out that within a few years the Scheme based version will have user-facing features that make people say "Wow. The old Emacs couldn't do that!" -t