From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?U8O4cmVuIFBpbGfDpXJk?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Fri, 7 Oct 2016 18:18:56 +0200 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1475857325 31389 195.159.176.226 (7 Oct 2016 16:22:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Oct 2016 16:22:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Brinkhoff Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 07 18:22:00 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsXtr-0004HY-TH for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2016 18:21:32 +0200 Original-Received: from localhost ([::1]:37163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsXtq-0001nO-Eb for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2016 12:21:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsXrQ-0000hb-2R for emacs-devel@gnu.org; Fri, 07 Oct 2016 12:19:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsXrO-0003mI-Lq for emacs-devel@gnu.org; Fri, 07 Oct 2016 12:18:59 -0400 Original-Received: from mail-ua0-x236.google.com ([2607:f8b0:400c:c08::236]:34007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsXrO-0003lf-Fr for emacs-devel@gnu.org; Fri, 07 Oct 2016 12:18:58 -0400 Original-Received: by mail-ua0-x236.google.com with SMTP id p25so48942699uaa.1 for ; Fri, 07 Oct 2016 09:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QO2uT5maN5iPP0aaTvB/Awv22CJ28yrWuqVupCrzMFw=; b=KNnoBiXW5eeTXgPIX6iycL06nbSVmY2Xv5RUZ8eO7QoBfySQtgg9ymqnIcgx5dqajE wG4yobyrKqh+GQ6sgn31qtpJvcqgR+eLQvCgDMmp6h7vt69LoRXe/347ac78ozov0Q4F rhC+2D8FKle+Xh4srtUqZfJGfMHfErhDVKURiCIznJs2cIrNnGO3o9ha1ThDcAFITHZz tFaHb+l8lD/b16OkDSPm7zQKAIIwjGfX9+D9TUn8omRIayy1QPBwqwb1WhrroFTDbmRj 5AcFAicoiQXVU1TqFFrYGeda99vkSc9RFMUHsaoH/cLMGWCi/ampLlxoDqfkZy4WSo8V vAtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QO2uT5maN5iPP0aaTvB/Awv22CJ28yrWuqVupCrzMFw=; b=GjewMBByCCEqggtiGIjc4WLHJ0ynblteKqXdTXAPcZZpLb6GKjzdjDCaAEHpmNuYAX mek2aOJI22YuYjCszX02euO+jIvD46i77fVT+KnqinR9/yAjMwBB0oIJeBpTuflH30dI WWRI8Q/wbwXY1REtcDJMo+U6n9Q2+yTiEF6e8NNkTPsHRMvtfWL22FoZo6PugYBo6Jbf /WGJWMOhtAO7j6i7cNK+7b5MQsrwWpgYObUQl8FZ1Q20yUyG9MI0tBnsJQuJEwnt3PM2 HUkSP2Gj/klVKc8A7eXPz4amoUAbkxnVgKTbhISbK8EM7IyG8YonleHOQeLp1BxSMX8s w/IA== X-Gm-Message-State: AA6/9RkiF1mzWDDfuyw7/F3rr4EAK5lMYqLlPZ7JPz4NDu5NrUBORiwYwsRNG2xvr4o2mrw2QYWWS9rtDtZjQg== X-Received: by 10.159.48.4 with SMTP id h4mr14696551uab.52.1475857137157; Fri, 07 Oct 2016 09:18:57 -0700 (PDT) Original-Received: by 10.103.48.141 with HTTP; Fri, 7 Oct 2016 09:18:56 -0700 (PDT) In-Reply-To: <86k2dk77w6.fsf@molnjunk.nocrew.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208062 Archived-At: On Fri, Oct 7, 2016 at 12:47 PM, Lars Brinkhoff wrote: > Now that we have new maintainers, I'd be curious to hear if they have > any thoughs on this? (See the original post for more information.) > > Stefan Monnier wrote two years ago: >> I've had the opportunity to think a bit more about Emacs Lisp and its >> possible evolution and I'm still not sure what to think about it. >> [...] >> I think that ideally, we'd want to stick to Elisp, or some evolution >> thereof. Sadly, I don't see how to evolve Elisp into Scheme: they are >> closely related languages, but the differences are large enough that >> it seems hard to reconcile them. >> >> The only standard language into which Elisp can evolve, AFAICT, is >> Common Lisp. [ Now some readers get disappointed, while some others >> become excited. ] There are some incompatibilities between the two >> languages, but I can imagine working them out over the years, or even >> living with them without too much trouble, such that we could use >> Common-Lisp libraries in Emacs. > > First of all we need to decide what it really is that is wanted here. Is it just the underlying lisp engine or what exactly? Is it basically replacing the C parts with Common lisp code? That does not seem to gain much. Is it to discard Emacs lisp entirely (maybe in a longer process) and replace it with Common lisp This would discard decades of code and mountains of configurations for what gain exactly? Or is the goal to find a mapping of Emacs lisp to Common lisp. So we can build up the core concepts in common lisp and then map whatever Emacs code down into Common lisp? Then people will ask next if in the future can code for Emacs directly in Common lisp and not just in "legacy" Emacs lisp. Keeping this distinction in mind is important, especially when talking to people outside the development group. A lot of people had very different ideas and interpretations of what the Emacs-guile project intented to do and did. Be aware that Emacs lisp is not Common lisp and such a mapping does have some pitfalls, especially around dynamic scoping and buffer local variables. I remember some blogposts about this (from 2012) http://tromey.com/blog/?p=709 http://tromey.com/blog/?p=751 http://tromey.com/blog/?p=778 Personally I could fear that this mapping will insert certain restrictions of what can and can't be done in Common lisp code against Emacs, especially if we open up to everyday Emacs code in Common lisp. Basically it would be problematic if Common lisp could violate certain assumptions the Emacs code makes, like running "single threaded". Maybe this could be contained by hiding it somehow, but isn't all we get another internal implementation then? If the developers prefer to do the internal implementation in Common Lisp/Emacs Lisp rather than C/Emacs lisp and have easier access to expose some libraries then that is another thing. So when people talk about Emacs Lisp transitioning to Common Lisp, please specify exactly what you want.