From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Taylan Ulrich Bayirli/Kammer Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 17:07:20 +0200 Message-ID: <878uliwajb.fsf@taylan.uni.cx> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410966466 22505 80.91.229.3 (17 Sep 2014 15:07:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 15:07:46 +0000 (UTC) Cc: Phillip Lord , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 17:07:39 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUGpX-0007mL-04 for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 17:07:39 +0200 Original-Received: from localhost ([::1]:45561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGpW-0004Dc-Gz for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 11:07:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGpM-0004DQ-Te for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:07:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUGpL-0001gh-9u for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:07:28 -0400 Original-Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:37126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUGpL-0001fq-2D for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:07:27 -0400 Original-Received: by mail-la0-f54.google.com with SMTP id ge10so2082877lab.27 for ; Wed, 17 Sep 2014 08:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=dITtJVD2ycWCL5xtMQJpR10TBFnH12oqfrfz3/g8Emo=; b=NjqRVAmpqMugPhKtCzj62fMnO3NQE5rdzOWoIL+b7OBsThftz4kco2jShtWvGFh0yh dpLOZj+J3kB+ZuSVXBdqIZIh9D0XO3Uro3UGb1f1H2p8/YZECnUBgs0KJ3G47Ywgwpp/ RTiZ2A3RQ1Z9R8w0FAp60cjQRx/+lqqrCR97yp/Y21Z19FpVXaawhpi7g6vlyWCGbMJ9 emvpnMnYUkTitX3ZtuFQhh7nX5+/OzaJBJCWUaU9bfKpD2iFvBt+UJeM7dFPUIFbbM7W DJ/dyccPEYsL3dNK8upGejbRIzpUQqeVazdWNc/45ZYrFVluQjQtpyPICiC94NHIJC38 pfiw== X-Received: by 10.152.19.66 with SMTP id c2mr45643597lae.64.1410966442908; Wed, 17 Sep 2014 08:07:22 -0700 (PDT) Original-Received: from taylan.uni.cx (p200300514A48ABEE0213E8FFFEED36FB.dip0.t-ipconnect.de. [2003:51:4a48:abee:213:e8ff:feed:36fb]) by mx.google.com with ESMTPSA id li3sm4386388lab.25.2014.09.17.08.07.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Sep 2014 08:07:22 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 17 Sep 2014 08:50:45 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174435 Archived-At: Stefan Monnier writes: > Interoperability between languages is *hard*. Doing it so the result > is lightweight and elegant (and moderately efficient) is rarely > possible. Well, the Elisp and Scheme integration is pretty great. Maybe you know all of the following, but for those who didn't: - There's no data type conversion because the same object in memory is the right type in both languages, including procedures/functions. - A convenient `import-guile-module' syntax in Elisp could be implemented relatively trivially, which would walk a module and put procedure bindings into the function namespace and other bindings into the variable namespace of Elisp (both with a user-provided prefix). So you can have the API of any Guile module in Elisp as if it were just an Elisp library. - There's simply no efficiency issue. After you import something from the other language, you just have it; it's indistinguishable from something you defined in the current language, analogous to how C implemented functions (subrs) are generally indistinguishable from Elisp implemented functions; they're now all "libguile procedure objects." - I can trivially import the Elisp function and variable namespaces in Scheme code with a pair of different prefixes. I then have the whole Elisp API in my Scheme code, sans Elisp macros. And here some issues, maybe-issues, and non-issues we have: - Currently strings are an exception to the first point. I hope that won't be too difficult to fix. - The handling of nil vs. Scheme #f and '() is admittedly a wart, but will probably remain hidden, not causing issues in code you write. - Currently Guile's Elisp implementation is buggy and slow in some things, but this is unrelated to the interoperation of the languages. - Conceptually, Scheme macros can work in Elisp. Might need some work to actually make this work, or it might be trivial; I don't know. - The biggest long-term issue might be that Elisp macros will not work in Scheme, and this is relevant only to people who want to use Elisp APIs in Scheme, not affecting Elisp users. If Guile-Emacs succeeds, you really will be able to (import-guile-module (gl) gl-) ;`gl-' is the prefix and write OpenGL code in Elisp. You can probably already do that in the current state of Guile-Emacs, except that `import-guile-module' needs to be implemented; for now you can individually do e.g.: (defalias 'gl-set-draw-buffer (guile-ref (gl) set-gl-draw-buffer)) I think this is worth pursuing. It opens Emacs to a whole new world. Yes, a lot of work needs to be done, but I see no fundamental problems. If some Emacs developers gave Guile-Emacs some love, it might land in a couple years I'd guess, and by then Guile will possibly have some form of just-in-time and/or ahead-of-time native compilation for Elisp as well as Scheme... Taylan