From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lally Singh Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future (was: Guile emacs thread (again)) Date: Wed, 17 Sep 2014 15:25:32 -0400 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <20140917202418.240bbd2c@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2d7b4dec2a7050347d4c2 X-Trace: ger.gmane.org 1410981952 11879 80.91.229.3 (17 Sep 2014 19:25:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 19:25:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 21:25:46 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 1XUKrJ-0006NY-Mr for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 21:25:45 +0200 Original-Received: from localhost ([::1]:46939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUKrJ-000754-9v for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 15:25:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUKrF-00074n-Jj for emacs-devel@gnu.org; Wed, 17 Sep 2014 15:25:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUKrC-00057f-6x for emacs-devel@gnu.org; Wed, 17 Sep 2014 15:25:41 -0400 Original-Received: from mail-vc0-x231.google.com ([2607:f8b0:400c:c03::231]:49934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUKrB-00056w-V9 for emacs-devel@gnu.org; Wed, 17 Sep 2014 15:25:38 -0400 Original-Received: by mail-vc0-f177.google.com with SMTP id im17so48906vcb.36 for ; Wed, 17 Sep 2014 12:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CxThYOeqHBCYBrUYlfg/YzUbN5X7OxW7oA29Qq88Z2w=; b=sVShUVaO0h22ZFSSpcgkQkxxaqKgUaUjfSWgKdNGDqxh2Dt27ElQ/i6RArSOdQC5qp WBGI4xg3r1NbqkHAjL5iMqNkDAk5w1a/g1cz3t7lnFk2WRRnDTb1b6xcyTIQgGhqBBjk qS68QbLdvbDL0UGclOsTBaVBfyIgz1v+HQxI/SSBvc55IFT60wc0wgD8v/wtSflSNaVm swzlV3xV63XFxL1Jc++aT8q4YyhdHgYIfKHUrNjGjvZyJT8QTX5d29zATyH6ZuHMIOLK UZ83t0Z7QBe1cPrPMcTj4kfm1/ye3y/G5rpTCulNx6akKv/iw/SAGktG8387zcBNfkVy 4rCw== X-Received: by 10.52.163.52 with SMTP id yf20mr30228664vdb.40.1410981932481; Wed, 17 Sep 2014 12:25:32 -0700 (PDT) Original-Received: by 10.52.109.132 with HTTP; Wed, 17 Sep 2014 12:25:32 -0700 (PDT) In-Reply-To: <20140917202418.240bbd2c@forcix> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c03::231 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:174460 Archived-At: --001a11c2d7b4dec2a7050347d4c2 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 17, 2014 at 2:24 PM, Jorgen Schaefer wrote: > On Tue, 16 Sep 2014 18:03:17 +0200 > Lennart Borgman wrote: > > Perhaps also the lack of possibility to enhance Emacs with code > > written in other languages? I think for example that Javascript will > > be something most future programmers will know. Could Guile make it > > easier to enhance Emacs with Javascript (as an alternative to Elisp)? > > I think the (often-cited, not just here) idea of supporting multiple > languages is a red herring, mostly. Every extension language supported > adds some burden on those who want to understand what their editor > does, not just use pre-packaged code. One of the great things about > Emacs is that, once I know ELisp, I have a good chance of understanding > and modifying any extension I see. And learning Emacs Lisp is not > exactly hard. > I think a policy of "if written for emacs, do it in elisp" is a good one, but let's acknowledge the advantage of easy linking/calling into other code bases that may come with having a multi-language-compatible runtime system. I'm sure we've all seen some systems that we'd love to invoke directly from elisp. > [snipping some very good points] One thing I think would benefit Emacs Lisp as a language a lot would be > a standard library cleanup. An effort to go through the libraries that > come with Emacs, separate them into "standard library" and "extensions > that come with Emacs", and then go through the "standard library", > provide sane names when necessary (like setcar is provided for rplaca) > and deprecating the old ones, or simply deprecate all but one version of > functions with overlapping use (nth or elt, pick one). Finally, add > standard libraries for common functionality that is currently lacking > (see above). > I completely agree that there's plenty of work needed there, but: - If staying with elisp, this is a separate discussion - If not staying with elisp, these problems can be addressed during conversion. --001a11c2d7b4dec2a7050347d4c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Sep 17, 2014 at 2:24 PM, Jorgen Schaefer <forcer@forcix.cx><= /span> wrote:
On Tue, 16 Sep 2014 18:03:1= 7 +0200
Lennart Borgman <lennart.bo= rgman@gmail.com> wrote:
> Perhaps also the lack of possibility to enhance Emacs with code
> written in other languages? I think for example that Javascript will > be something most future programmers will know. Could Guile make it > easier to enhance Emacs with Javascript (as an alternative to Elisp)?<= br>
I think the (often-cited, not just here) idea of supporting multiple
languages is a red herring, mostly. Every extension language supported
adds some burden on those who want to understand what their editor
does, not just use pre-packaged code. One of the great things about
Emacs is that, once I know ELisp, I have a good chance of understanding
and modifying any extension I see. And learning Emacs Lisp is not
exactly hard.

I think a policy of "= ;if written for emacs, do it in elisp" is a good one, but let's ac= knowledge the advantage of easy linking/calling into other code bases that = may come with having a multi-language-compatible runtime system. =C2=A0I= 9;m sure we've all seen some systems that we'd love to invoke direc= tly from elisp.
=C2=A0
[snipp= ing some very good points]=C2=A0
One thing I think would benefit Emacs Lisp as a language a lot would be
a standard library cleanup. An effort to go through the libraries that
come with Emacs, separate them into "standard library" and "= extensions
that come with Emacs", and then go through the "standard library&= quot;,
provide sane names when necessary (like setcar is provided for rplaca)
and deprecating the old ones, or simply deprecate all but one version of functions with overlapping use (nth or elt, pick one). Finally, add
standard libraries for common functionality that is currently lacking
(see above).

I completely agree that th= ere's plenty of work needed there, but:
=C2=A0- If staying wi= th elisp, this is a separate discussion
=C2=A0- If not staying wi= th elisp, these problems can be addressed during conversion.

=
--001a11c2d7b4dec2a7050347d4c2--