From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Elias_M=C3=A5rtenson?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Tue, 11 Oct 2016 22:44:01 +0800 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <642fd4b4-8b1c-a537-5a5f-6940691ec4b9@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c06dde450c3ea053e97e877 X-Trace: blaine.gmane.org 1476197448 4205 195.159.176.226 (11 Oct 2016 14:50:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2016 14:50:48 +0000 (UTC) Cc: rms@gnu.org, emacs-devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 11 16:50:44 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 1btyNu-00072W-NX for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2016 16:50:26 +0200 Original-Received: from localhost ([::1]:56258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyNt-0007Fl-FS for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2016 10:50:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyIF-0003y0-V1 for emacs-devel@gnu.org; Tue, 11 Oct 2016 10:44:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btyID-0007fu-UH for emacs-devel@gnu.org; Tue, 11 Oct 2016 10:44:34 -0400 Original-Received: from mail-qk0-x233.google.com ([2607:f8b0:400d:c09::233]:34231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyID-0007fn-Om; Tue, 11 Oct 2016 10:44:33 -0400 Original-Received: by mail-qk0-x233.google.com with SMTP id f128so35923328qkb.1; Tue, 11 Oct 2016 07:44:33 -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=JJsYJHdLMAFPk3zkhhNOZuwyyTcFVadS5m9sAJ19h1c=; b=DUGwcs3knfz8iS1HbilkxMzVJxQ6pHAFyl6UqjNlr+sLVNFoyEKYcy5b9+JjLdlCIm VywYWPfC4gHaLPIp5Tvg0xZ+eq+zg4W0Ht1mdUEgHwhIFQvpuopz9vX8oJan+GHwHbnH /v1XumFqj8VkwzpZ+VBko5WENxEumLG2h1v+jxBWtA4TeZY3z6E/JBTYPb/7JxPr38je xtV+QNseSteeFfLeoVlLdsCoXVxXqYsu2+TwrPE+ZoqBFAwED2P86XFcKUqAYdJgFVki RVwSbpTGWxazGrX+AxUuHK0PnBwYiYpZ4ApR1xGguet4CkpaSNtUMVj7sv37qIgOf1dG dpog== 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=JJsYJHdLMAFPk3zkhhNOZuwyyTcFVadS5m9sAJ19h1c=; b=aZnJ9lKMcjKIRLIONhhG9yn1arSYUdTMIn8VAGbZ2hOZoOrwmib7bX5C0791fJOBfE HYzKuL/Y3UOJfNOY+dvLGXhxA3mgYm64z//2ImB7ODxi8ec7cl6Ekujq2b1wRmPScCSI BxlF08TvotLFrE6tjLrkgR4xx363PXi3HAOwS0gpeyNmKtmo0IQWP3V2jMpb6M6WJuD0 WvUaZdodXgrVyBe582AAhTnzD2eRi88EgHEhhPh8Vn4x5ruJA8yTsoHRre8ulyqmgIga PhjN/ZIiiVAGoU9Di3DEM/idf4yJJ8ckENjTiAwDf3TMi9+bkz80sJ3Dwn7ZePBMI/pm iRSQ== X-Gm-Message-State: AA6/9Rm2VMxdvgmmT++XbYLrfSBjEOE9mLFKrEJcEGG0yL/wJf1Ca/nBKztPd4EuWY2harrPaBGwOPaxbBx3dw== X-Received: by 10.55.162.150 with SMTP id l144mr4030370qke.72.1476197042141; Tue, 11 Oct 2016 07:44:02 -0700 (PDT) Original-Received: by 10.55.55.2 with HTTP; Tue, 11 Oct 2016 07:44:01 -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:400d:c09::233 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:208160 Archived-At: --94eb2c06dde450c3ea053e97e877 Content-Type: text/plain; charset=UTF-8 On 11 October 2016 at 15:47, Helmut Eller wrote: > On Mon, Oct 10 2016, Richard Stallman wrote: > > > The reason namespaces systems do not fit well into Lisp > > is that they have to operate in 'read', in the choice of which > > symbol object you get. > > I would say that namespaces manage symbols. In contrast, modules manage > bindings. > That's an interesting way of putting it. > The annoyance in Common Lisp is mostly that packages have to exist > before READ can intern symbols in a particular package. That would be > problematic for autoload cookies or customizations in .emacs which are > commonly executed before loading the code that actually defines the > package. > That can be dealt with by transparently creating a package during READ. Common Lisp doesn't do this, but it can be argued that it should. > The other annoyance in Common Lisp is that occasionally one gets name > conflict errors when importing a package because a symbol was > accidentally interned in the current package with READ. People then > often get confused by the error message and quickly jump to the > conclusion that the package system must suck. It's in fact a pilot > error and the package system just does its job of keeping the namespace > clean. > What I do is simply never importing symbols from other packages. If I need to refer to a symbol in a different package, I always fully qualify it. If a package system was implemented in Emacs Lisp, it would make sense to enforce this. Elias --94eb2c06dde450c3ea053e97e877 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 1 October 2016 at 15:47, Helmut Eller <eller.helmut@gmail.com>= wrote:
On Mon, O= ct 10 2016, Richard Stallman wrote:

> The reason namespaces systems do not fit well into Lisp
> is that they have to operate in 'read', in the choice of which=
> symbol object you get.

I would say that namespaces manage symbols.=C2=A0 In contrast, modul= es manage
bindings.

That's an interesting way= of putting it.
=C2=A0
The an= noyance in Common Lisp is mostly that packages have to exist
before READ can intern symbols in a particular package.=C2=A0 That would be=
problematic for autoload cookies or customizations in .emacs which are
commonly executed before loading the code that actually defines the
package.

That can be dealt with by tran= sparently creating a package during READ. Common Lisp doesn't do this, = but it can be argued that it should.
=C2=A0
The other annoyance in Common Lisp is that occasionally one = gets name
conflict errors when importing a package because a symbol was
accidentally interned in the current package with READ.=C2=A0 People then often get confused by the error message and quickly jump to the
conclusion that the package system must suck.=C2=A0 It's in fact a pilo= t
error and the package system just does its job of keeping the namespace
clean.

What I do is simply never import= ing symbols from other packages. If I need to refer to a symbol in a differ= ent package, I always fully qualify it.

If a packa= ge system was implemented in Emacs Lisp, it would make sense to enforce thi= s.

Elias
--94eb2c06dde450c3ea053e97e877--