From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: adding namespaces to emacs-lisp (better elisp?) Date: Fri, 26 Jul 2013 11:43:40 -0400 Message-ID: References: <874nbh2z3y.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374853427 3203 80.91.229.3 (26 Jul 2013 15:43:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 15:43:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nic Ferrier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 26 17:43:48 2013 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 1V2kBI-0000gY-CK for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 17:43:48 +0200 Original-Received: from localhost ([::1]:40885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2kBI-0002Wn-1Z for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 11:43:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2kBE-0002Vo-2y for emacs-devel@gnu.org; Fri, 26 Jul 2013 11:43:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2kBC-0007qe-FP for emacs-devel@gnu.org; Fri, 26 Jul 2013 11:43:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:64552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2kBC-0007qY-B6 for emacs-devel@gnu.org; Fri, 26 Jul 2013 11:43:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZPn/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgzBIZEKA6R6gV6DEw X-IPAS-Result: Av4EABK/CFFFpZPn/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgzBIZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="19910236" Original-Received: from 69-165-147-231.dsl.teksavvy.com (HELO pastel.home) ([69.165.147.231]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 Jul 2013 11:43:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id EABB462D1A; Fri, 26 Jul 2013 11:43:40 -0400 (EDT) In-Reply-To: <874nbh2z3y.fsf@ferrier.me.uk> (Nic Ferrier's message of "Fri, 26 Jul 2013 15:08:01 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:162143 Archived-At: > We had a lot of discussion recently about making EmacsLisp I'm not sure I understand: do you mean Emacs does not Lisp enough yet? > Here http://nic.ferrier.me.uk/blog/2013_06/adding-namespaces-to-elisp is > a proposal to add namespaces to emacs-lisp. Comments: - "Interning a symbol with "::" in it should no longer be possible. It should raise an error." Why not simply intern it in the corresponding namespace? It's probably a bad practice, but Emacs is usually not in the business of preventing bad practice. - I'm not sure how well it will cope with shadowing and non-namespaced symbols (e.g. symbols like `face' that aren't used as variables). The rule "global obarray is inspected first and if a symbol is found there that's what is used" means that we have to be vary careful about interning things in the global obarray since it can affect the way other code is handled. Currently, we're very liberal about interning in the global obarray. Basically I think this shadowing rule makes things a bit too automatic for something where we need more control. I think that, for backward compatibility reasons we can't easily mark "non-prefixed symbols that should be global" (such as `face'), so the safer alternative is to force local symbols to be specially marked (like ::foo, maybe, to mean "foo in the current local obarray"). Having to prefix every single local symbol that way probably sounds rather unpalatable, tho. - I'm not sure exactly how you expect importing namespaces should/will work. -- Stefan