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: Tue, 13 Apr 2010 11:56:40 -0700 Message-ID: <1271185000.6067.70.camel@dell-desktop.example.com> References: <4B8147A9.7030504@gmail.com> <87hbp2fwoi.fsf@gnu.org> <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 1271185018 13944 80.91.229.12 (13 Apr 2010 18:56:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Apr 2010 18:56:58 +0000 (UTC) Cc: Bruce Stephens , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 13 20:56:55 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 1O1lI2-0000lk-Ge for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 20:56:50 +0200 Original-Received: from localhost ([127.0.0.1]:52202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1lI2-0000zx-0l for ged-emacs-devel@m.gmane.org; Tue, 13 Apr 2010 14:56:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1lHv-0000zS-K3 for emacs-devel@gnu.org; Tue, 13 Apr 2010 14:56:43 -0400 Original-Received: from [140.186.70.92] (port=38077 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1lHu-0000zG-8L for emacs-devel@gnu.org; Tue, 13 Apr 2010 14:56:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1lHr-0002ZA-N4 for emacs-devel@gnu.org; Tue, 13 Apr 2010 14:56:42 -0400 Original-Received: from smtp171.iad.emailsrvr.com ([207.97.245.171]:36050) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1lHr-0002YU-HP for emacs-devel@gnu.org; Tue, 13 Apr 2010 14:56:39 -0400 Original-Received: from relay17.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay17.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 109D71B4039; Tue, 13 Apr 2010 14:56:39 -0400 (EDT) Original-Received: by relay17.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 504B31B9696; Tue, 13 Apr 2010 14:56:38 -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:123592 Archived-At: On Tue, 2010-04-13 at 12:07 -0400, Stefan Monnier wrote: > I agree with your conclusion but for a very different reason. > In my opinion the actual language used is not very important because > most of the code that will be used with Emacs will be written > specifically for Emacs. Well, I'm not so sure that that's entirely true and I'm also not so sure that that's the only consideration. What you say is less than obviously true in this way, at least: Consider how modern browsers are often written. On the one hand there is some lower-level library for rendering HTML and doing various HTTP magic. On the other hand, there are higher levels that make the complete application. That lower level part gets re-used in other applications. A text editor isn't obviously much (or perhaps at all) a different case. It might be desirable to start thinking of Emacs in two layers: an embeddable library and, sure, a default application as its basic front-end. Emacs lisp library code would then be "emacs specific" in some sense (relative to the library) but not really application specific. Beyond that: While it might be the case that "most" Emacs lisp library code is Emacs-specific in some sense, some important code need not be. One example is SCSH (the Scheme "shell" for managing sub-processes). A possible future example is Unicode-oriented string libraries. "Most" of the code might be Emacs-specific but some important parts of the code need not be. And, anyway, it's not the only consideration. If Scheme were used by many GNU programs as an extension language, then inter-process communication by writing and reading Scheme s-exps would be more common. Two standard Scheme environments can exchange s-exps with relatively little problem. But toss in a very different lisp - like Emacs lisp - and you start to have problems. E.g., what does "nil" read as? What's the syntax for strings? Are symbols case sensitive? > The availability of alternative implementations is also of no use > because changing the underlying implementation is the part that's > difficult (at least with Emacs's current structure). Sure. But if we're thinking of a long term strategy rather than quick hacks, we should also keep in mind that much of what is today in C in Emacs could well be usefully replaced by Scheme code. That's part of why I suggest (you know, given the infinite amount of spare time we all have) the radical option of stripping Emacs lisp out and re-binding to Scheme: because that exercise would lead to some careful re-evaluation of what needs to be in the C part and how best to make a clean interface to it. > What matters is that we reuse some existing implementation and benefit > from all the work done on it, so we don't have to spend time working on > the Elisp byte-compiler. I fully agree that that matters. > I like the idea of Guile not because it's using a "standard preexisting > language with libraries and experienced coders", but because it'll give > us a bunch of hackers working on efficient implementation, > multithreading, ... Yup. A big "gotcha" trap to watch out for on that path is Guile's C API. The less intertwingled Guile's (or any other implementations) assumptions about the C client can be, the better and more flexible the result. I.e., it would be pretty much the same mistake as being too Emacs lisp centric to be too Guile centric. It would ideally be plausible to swap out Guile for some other implementation, even if the initial investment and commitment is to use Guile. -t > > Stefan > > > PS: The same holds for the redisplay engine; I really hope/wish we will > be able to switch to some other project's redisplay engine at some point. > >