From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Fri, 07 Oct 2016 16:25:25 +0000 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c1925122e1a22053e48dceb X-Trace: blaine.gmane.org 1475857961 17456 195.159.176.226 (7 Oct 2016 16:32:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Oct 2016 16:32:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?B?U8O4cmVuIFBpbGfDpXJk?= , Lars Brinkhoff Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 07 18:32:36 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 1bsY4N-0002gw-Gy for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2016 18:32:23 +0200 Original-Received: from localhost ([::1]:37221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsY4M-0001Qi-0M for ged-emacs-devel@m.gmane.org; Fri, 07 Oct 2016 12:32:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsXxr-0005xo-TA for emacs-devel@gnu.org; Fri, 07 Oct 2016 12:25:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsXxo-0008Qf-W3 for emacs-devel@gnu.org; Fri, 07 Oct 2016 12:25:38 -0400 Original-Received: from mail-ua0-x22f.google.com ([2607:f8b0:400c:c08::22f]:33155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsXxo-0008QT-Ju for emacs-devel@gnu.org; Fri, 07 Oct 2016 12:25:36 -0400 Original-Received: by mail-ua0-x22f.google.com with SMTP id p102so49150668uap.0 for ; Fri, 07 Oct 2016 09:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L3GATuoX4d1Y/uVvqulm36JmFdziSHqj/beAkYjWWgM=; b=cRcK2r2BO0t2elVjMpsTMtHODRPW8yyj+uuA2WiQVfaOAV/5Pc+jLytVwyD2KfPeYd c0x+p41AHbxrCzwCh1Q/KLwENLf2sjjwpic+FLtcD4Jihedj/4DHxPB202sd7Bjp/E+4 Dkw6zIuYLcSPQkAqeHByBbuWEU5UgT0c6tPAbcxpE6NCF54t2meICfAxv4YWf59WlIQO UUO2CIGS7KF9C3ugP39iKd/FI2do28BhWlw6TmvaLjDEAf1ufaaifs5AlZuMmwGsSTFx +pRbU+Lb6RjWr+hFSqvSVZQx8Q2AO3tLnkEBOoftmCDau0vGOi00wz2gEeazyCorCwWx e31Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L3GATuoX4d1Y/uVvqulm36JmFdziSHqj/beAkYjWWgM=; b=F7wWnoXZ9ZtGLeWMeR+v/zvP+fIJEy8JhMSCtSSF57D4M8JRnsXEB9okfsWrhidu2M rhkhOMvKmKHRrbSf3I0K9qqgpcZ8MHu6HiZC2nZpvcMFyMqwGHNXnqxTYSDiRk7x6cMY OWcWJATN0NFRAADLPeKszJp+BbgfpUWxhp130yOVD0uEAuG3LbKQIDM3vyWZSC8odl6x nPY35afR3iX3h7QB0y6Sv5gokTF3WtVS1k4rb6hr2fP0k34z0uNidQqEYirkh1MG9sVq NVCMEe46tWEzd3TIFF2Z7UneRz8OiGGWmy9XIq7KAoSpJu6wImM/Jrzn51yP+7lyNxYR MBHA== X-Gm-Message-State: AA6/9Rn7d1fmBn21Y/z7FiFX7EqwZ+jYLnUI/x83TjXoflHmsBbmjbudArIgl1JarLRR/jwwWWlET0YkYS73iQ== X-Received: by 10.176.82.161 with SMTP id v30mr15118492uav.28.1475857536127; Fri, 07 Oct 2016 09:25:36 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::22f 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:208063 Archived-At: --94eb2c1925122e1a22053e48dceb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2016 at 12:20 PM S=C3=B8ren Pilg=C3=A5rd wrote: > 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=3D709 http://tromey.com/blog/?p=3D751 > http://tromey.com/blog/?p=3D778 > > 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 ope= n > 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. > Exactly my thoughts. My fear is that this supposed transition to Common Lisp with fragment the emacs user base.. some will stick with elisp and some will move over to CL. Elisp is working very well for configs and packages. We should rather stick with it and keep on growing the codebase in the same language. (If Elisp is completely discarded, we will not have enough people to convert *all* existing cool packages discovered and yet to be discovered from elisp to CL.) So it is a lose-lose situation whether Elisp and CL co-exist or even if CL completely replaces Elisp. --=20 Kaushal Modi --94eb2c1925122e1a22053e48dceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oc= t 7, 2016 at 12:20 PM S=C3=B8ren Pilg=C3=A5rd <fiskomaten@gmail.com> wrote:
First of all we need to decide what it really is that is wa= nted 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=3D709 http://tromey.com/blog/?p=3D751
http://tromey.com/blog/?p=3D778

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 o= pen up to
everyday Emacs code in Common lisp. Basically it would be problematic if Co= mmon
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.
<= div>

Exactly my thoughts. My fear is that this= supposed transition to Common Lisp with fragment the emacs user base.. som= e will stick with elisp and some will move over to CL. Elisp is working ver= y well for configs and packages. We should rather stick with it and keep on= growing the codebase in the same language.=C2=A0

= (If Elisp is completely discarded, we will not have enough people to conver= t *all* existing cool packages discovered and yet to be discovered from eli= sp to CL.)

So it is a lose-lose situation whether = Elisp and CL co-exist or even if CL completely replaces Elisp.
<= /div>
--
=

Kaushal Modi

--94eb2c1925122e1a22053e48dceb--