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 22:11:10 +0200 Message-ID: <87wq92uhwh.fsf@taylan.uni.cx> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <878uliwajb.fsf@taylan.uni.cx> <87lhpitg6t.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410984720 14146 80.91.229.3 (17 Sep 2014 20:12:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 20:12:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 22:11:51 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 1XULZv-0006Jf-BL for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 22:11:51 +0200 Original-Received: from localhost ([::1]:47080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XULZu-0000XB-R3 for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 16:11:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XULZS-0000IN-IO for emacs-devel@gnu.org; Wed, 17 Sep 2014 16:11:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XULZR-00005a-7G for emacs-devel@gnu.org; Wed, 17 Sep 2014 16:11:22 -0400 Original-Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]:50517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XULZQ-000051-Rc; Wed, 17 Sep 2014 16:11:21 -0400 Original-Received: by mail-lb0-f180.google.com with SMTP id b12so2613069lbj.11 for ; Wed, 17 Sep 2014 13:11:14 -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=1Oqou/zL02V4p+3LP6ow6BZzdGqKemRAk5hn+I361do=; b=Bquks91Pso9mD4PC8gYZhE+f7xYd1bU9hvxu/txRYaxGct0ga6xPQmrxFLoF5GQHm9 N2ir1lM4XeWOIcVMBDQ1pyppsh4B9KyaM+qQJKodbTA6X4LfsvcV3ZGJ8mUPYNqtiPXG +bUm6gt6VCTuxRsqKTzolcOQj/AEe1S5x8Fyf0svHfKxjCOu8Ye+cLTPRNDj5ZuU4o8S bY4/XwZbyo38wJp2ZQqFx/mIiw0F7BokIvfzYRdVuvyY2g1gPfV9T34qtK3gsQpAiPVf 2ehFV/QZBTM1ouibY6WnegelqTnCGTmvCSwRJCzgoNsr9s/IplOBweqg31ODl+7SomFr /eJA== X-Received: by 10.152.115.195 with SMTP id jq3mr67275lab.90.1410984674056; Wed, 17 Sep 2014 13:11:14 -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 nb7sm6469596lbb.43.2014.09.17.13.11.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Sep 2014 13:11:13 -0700 (PDT) In-Reply-To: <87lhpitg6t.fsf@fencepost.gnu.org> (David Kastrup's message of "Wed, 17 Sep 2014 17:33:30 +0200") 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:c04::234 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:174464 Archived-At: David Kastrup writes: >> - There's no data type conversion because the same object in memory is >> the right type in both languages, including procedures/functions. > > Uh, no? In Lisp, functions are bound to the function cell of a symbol > which is different from the value cell of a symbol. In GUILE, nothing > is bound to a symbol at all. Modules establish a mapping between > symbols and values, and functions do not have separate mappings from > values. I'm not talking about the language-semantic locations of objects, rather that for example the same "physical" object in your RAM is at the same time an Elisp function, and a Scheme procedure. `functionp' and `procedure?' both check for the same data type. (Likewise for other types.) No mutation, packing, serialization/deserialization, or any other things needs to happen to a byte sequence in memory for it to be usable from either language. There's probably a simpler way to word what I have in mind and it's currently escaping me; hope this was clear enough. :) >> - 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." > > That's a misrepresentation since an import does not change the state of > a "libguile procedure object" but rather involves the establishing of > bindings. [...] Yes? I'm just saying that once you put a libguile procedure into the function slot of an Elisp symbol, it's indistinguishable from an Elisp function or a subr being in that slot. There is no overhead while calling it. (Elisp functions are compiled into libguile procedures anyway.) Actually, this is just a special-case of the first point, regarding the applicable data type (libguile procedures) being handled in a uniform way without extra overhead in the case it "comes from the other language." >> - The handling of nil vs. Scheme #f and '() is admittedly a wart, but >> will probably remain hidden, not causing issues in code you write. > > I have problems seeing how it can remain hidden. Please mention any concrete problematic cases you can think up. >> - Currently Guile's Elisp implementation is buggy and slow in some >> things, but this is unrelated to the interoperation of the >> languages. > > If it is unrelated to the interoperation of the languages, this would > imply that GUILE itself is buggy and slow. You might want to reconsider > that statement. It implies Guile's Elisp implementation is buggy and slow. That is one unfinished component of Guile. (The main body of the Elisp implementation that powers Guile-Emacs resides within Guile itself; I think some key Emacs data types like buffers and windows are missing if you use it purely from Guile instead of running Guile-Emacs, but you can use it as a general-purpose language.) >> - 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. > > Huh, this actually is a surprise to me since defmacro works pretty much > the same in GUILE/Scheme as it would in Elisp. The problem is that the Elisp macro will just output, say, the symbol `mapc' into the middle of your Scheme code, where it will not be bound to the Elisp `mapc' function during subsequent compilation. Of course, you can otherwise use defmacro in Scheme, though it's highly discouraged since you have hygienic macros, which guarantee correct bindings. >> Yes, a lot of work needs to be done, but I see no fundamental >> problems. > > The main problem I see is that Emacs is a large project regarding its > code and developer base compared to GUILE and I don't see that GUILE > can easily scale up. Matters such as portability and bug-fixing speed which are related to "manpower" seem open to improvement indeed. I think that would actually be a way in which the Guile-Emacs effort would pay back to Guile. If I'm not mistaken, adopting ECL or some other foreign piece of software would mean that the upstream developers of it aren't guaranteed to cooperate, which could be problematic despite the overall maturity of that piece of software. Guile on the other hand is GNU software; it's the official GNU extension language that's being massively revitalized to be worth of its name. GCC, GDB, and more can be extended in Guile. It's tied with Guix as well; the package manager for the upcoming official GNU distribution. After so many years, things are really getting together in technical terms in the GNU project, and Guile is what's pulling it all together. That's why I'm so interested in Guile myself, and think that Emacs just ought to be a part of this as well. There is some massive potential here for the whole of the GNU system getting a lot more attention, and Emacs itself will benefit from it greatly. One needs to give it time of course, but I think it's the right direction, and is what will be most beneficial to Emacs individually as well in the long term, in case one doesn't care about GNU. And of course, a large portion of the work is already done here. Another option would mean starting from scratch. > The priorities of Elispers and Schemers regarding language features and > focuses are different, and I don't see overrolling GUILE with the > requirements, code, interests, and developers of Emacs going smoothly. The priorities of Elispers seem extremely diverse. People hacked up web servers with Elisp and seem motivated to do crazier things. All the Guile libraries should be welcome. >> 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... > > Elisp is not really a special case here since stuff like native > compilation would happen at a decidedly lower layer than the > Elisp/Scheme distinction. GUILE has a rather impressive number of > compiler layers and it is probably only the top layer that would make > a difference between Elisp and Scheme while something like the two > bottom layers would distinguish between native compilation and > bytecode. Precisely. I just meant to stress out that whatever nifty low-level features Guile will improve on, Elisp, Scheme, and other languages on Guile will benefit from them automatically. Taylan