From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Tue, 11 Oct 2016 09:47:54 +0200 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: text/plain X-Trace: blaine.gmane.org 1476172162 1764 195.159.176.226 (11 Oct 2016 07:49:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2016 07:49:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: rms@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 11 09:49:18 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 1btro5-0006US-La for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2016 09:49:01 +0200 Original-Received: from localhost ([::1]:54217 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btro4-0000hW-Dg for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2016 03:49:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btrnV-0000h9-0p for emacs-devel@gnu.org; Tue, 11 Oct 2016 03:48:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btrnQ-0002BK-Qj for emacs-devel@gnu.org; Tue, 11 Oct 2016 03:48:23 -0400 Original-Received: from [195.159.176.226] (port=54832 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btrnQ-00026P-JL for emacs-devel@gnu.org; Tue, 11 Oct 2016 03:48:20 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1btrn5-0007Wp-Pa for emacs-devel@gnu.org; Tue, 11 Oct 2016 09:47:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:0LeIos+7jBThD8MSUif+B1hWCFw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:208154 Archived-At: 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. 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. 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. > I looked very briefly at the Clojure namespace spec and saw that it > operates as part of evaluation, not as part of reading. Perhaps that > explains why it is usable. Namespaces can work reasonably well as > part of evaluation. However, that doesn't fit Lisp. > > Clojure is not Lisp. I guess then Scheme isn't Lisp either. BTW, Rep, the Lisp dialect used by the Sawfish window manager which initially looked very similar to Emacs Lisp, also eventually added a module system. Apparently without too much trouble. Helmut