From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: ELisp? Date: Sun, 9 Oct 2011 15:22:36 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1318188168 13625 80.91.229.12 (9 Oct 2011 19:22:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 9 Oct 2011 19:22:48 +0000 (UTC) Cc: guile-devel@gnu.org To: joakim@verona.se Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Oct 09 21:22:43 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RCyxO-00078m-NW for guile-devel@m.gmane.org; Sun, 09 Oct 2011 21:22:42 +0200 Original-Received: from localhost ([::1]:35986 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCyxO-0003f4-8m for guile-devel@m.gmane.org; Sun, 09 Oct 2011 15:22:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCyxK-0003eo-Rh for guile-devel@gnu.org; Sun, 09 Oct 2011 15:22:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RCyxJ-0006Vz-Av for guile-devel@gnu.org; Sun, 09 Oct 2011 15:22:38 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:51519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCyxJ-0006Vt-6Y for guile-devel@gnu.org; Sun, 09 Oct 2011 15:22:37 -0400 Original-Received: by iaen33 with SMTP id n33so8701015iae.0 for ; Sun, 09 Oct 2011 12:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/Miz2+trouzi3aHfInHKHGECNBIL0jCMt97ll9wnD0k=; b=Wx8MlXBfAL8XP5xJdmNCoRdCSTHtWZJoLMvRQdKDL0dfDcxhAuHLaKugxtghmHbRAG K/rfT9pt+hmDfUfoDYggbibASLFUvo8SE9UoRqG0YWP3WU/IALQA6pKsCzrvw1vkn4U9 QSLQuCD3TOyI6J+E/N4s4j+3eYdmYCSBUaZns= Original-Received: by 10.42.154.7 with SMTP id o7mr11444978icw.48.1318188156308; Sun, 09 Oct 2011 12:22:36 -0700 (PDT) Original-Received: by 10.42.180.1 with HTTP; Sun, 9 Oct 2011 12:22:36 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: fEMcsTgZjgwwBwhQCDFb6PR7GBk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12831 Archived-At: That makes sense. I was hoping we could skip the phase where we have two lisp interpreters around, if Guile's ELisp implementation was good enough, but maybe that will not be possible. Emacs already does something similar to this for the programming language modes, where it has another interpreter as a subprocess, so this doesn't sound so bad technically. One question I have is, how much of Emacs' C code can Guile use right now? I guess Ken Raeburn's patches are the ones that address that, but I don't know what is left to do. (I also have the same question about ELisp - what of the language is left to implement? Is it just adding more builtins?) I don't know if this would work, but the way I was imagining it happening is really just starting up Guile and loading Emacs source files, one by one. If we have a complete ELisp implementation with all of Emacs' C code, then in theory Emacs would start. I don't know what would actually happen though. A branch on Savannah sounds like a really good idea though. Then at least there would be a central thing for people to look at and hack on, and more people might get involved. Right now I suspect that most people don't know what's happening or where to look. If you set up a branch, I for one would love to check it out and perhaps contribute some patches. Do you need permission from the Emacs maintainers to do that, or anything else? Noah On Sun, Oct 9, 2011 at 9:37 AM, wrote: > Noah Lavine writes: > >> Hello all, >> >> Could anyone tell me the status of the ELisp implementation since July >> 21st (the last update)? >> >> I'm especially interested now because of a thread on emacs-devel - >> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00753.html.Peop= le were talking about adding multithreading to Emacs. Some people >> said that moving Emacs to Guile might be the best solution, but others >> were pessimistic about that ever happening. It looks like the Emacs >> people would really like to use Guile, and we would certainly like >> them to. Also, every time Emacs implements a feature that Guile >> already has, it's wasted effort when we eventually integrate them. >> >> It seems like Emacs-Guile integration is a project that is on the >> verge of happening, and just needs some sort of push to get it over >> the hump. I hope that this summer's SoC work can be the impetus. >> >> Noah >> >> > > I'm an Emacs developer(not the most prolific but I have contributed > ImageMagick core integration and Webkit integration for Emacs 25) > > I'm now trying to learn non-trivial Guile usage so as to be useful in > the future merge of Guile and Emacs. > > Currently, for me coming from the Emacs side is that I have no idea how > integration would happen. I've studied the various attempts but haven't > come to any conclusion. > > My naive approach would be to make an Emacs Guile branch on > Savannah. The branch would unify incrementally the 3 different existing > approaches: > > =A0- Nishidas patches to run Guile in Emacs > =A0- Ken Raeburns patches to replace the Emacs Lisp engine > =A0- Templetons implementation of Elisp in Guile > > This branch would initially use Nishidas strategy of just linking Guile > and providing some simple interoperability functions. The version linked > would be Templetons Elisp Guile version. So, there would be 2 lisp > engines in Emacs for a while. When things work well the old Emacs lisp > engine would be ripped out. > > As I'm coming from the Emacs side of things my interest is in getting > Guile in the Emacs core efficiently. My motivation is somewhat selfish > because I don't want to re-implement all the interesting features Guile > has in Emacs, such as dynamic FFI etc.. > > Of course there are many details to work out. A random example could > be that we would like a cookie to indicate that eval-buffer should use > guile rather than elisp for a buffer. > > The advantage of the above approach is that it is incremental. We gain > exposure in the Emacs developer community. Since Emacs 24 is entering > pretest its a good time to start to think of features for Emacs 25. > > > > -- > Joakim Verona > > >