From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 17:33:30 +0200 Organization: Organization?!? Message-ID: <87lhpitg6t.fsf@fencepost.gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <878uliwajb.fsf@taylan.uni.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410968072 13996 80.91.229.3 (17 Sep 2014 15:34:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 15:34:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 17:34:23 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 1XUHFP-0001MW-5Y for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 17:34:23 +0200 Original-Received: from localhost ([::1]:45710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUHFO-000718-Nd for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 11:34:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUHF2-00070o-BH for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:34:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUHEw-0000t4-DK for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:34:00 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:36427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUHEw-0000sf-6Q for emacs-devel@gnu.org; Wed, 17 Sep 2014 11:33:54 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XUHEm-00018g-A8 for emacs-devel@gnu.org; Wed, 17 Sep 2014 17:33:44 +0200 Original-Received: from x2f502b3.dyn.telefonica.de ([2.245.2.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Sep 2014 17:33:44 +0200 Original-Received: from dak by x2f502b3.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Sep 2014 17:33:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 95 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f502b3.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:53TD6UPAv6ZZsoClz7x9vq0FHFU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:174442 Archived-At: Taylan Ulrich Bayirli/Kammer writes: > 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. 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. > - 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. See? > - 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. The data structures are also not compatible: Lisp lists end with a value that serves as a _false_ boolean, Scheme lists end with a value that serves as a _true_ boolean. > And here some issues, maybe-issues, and non-issues we have: [...] > - 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. > - 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. > - 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. Huh, this actually is a surprise to me since defmacro works pretty much the same in GUILE/Scheme as it would in Elisp. > 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. 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. > 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. -- David Kastrup