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 20:49:41 -0400 Message-ID: References: <874nbh2z3y.fsf@ferrier.me.uk> <871u6l2ral.fsf@ferrier.me.uk> <87siz116zo.fsf@ferrier.me.uk> <3b4713cb-5fd5-498b-b9ee-a676f0fef845@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374886189 22909 80.91.229.3 (27 Jul 2013 00:49:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jul 2013 00:49:49 +0000 (UTC) Cc: Nic Ferrier , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 27 02:49:49 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 1V2shg-0005w8-Gu for ged-emacs-devel@m.gmane.org; Sat, 27 Jul 2013 02:49:48 +0200 Original-Received: from localhost ([::1]:45842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2shf-0000ZT-I6 for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 20:49:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2shb-0000ZD-Ji for emacs-devel@gnu.org; Fri, 26 Jul 2013 20:49:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2sha-0006qf-Lb for emacs-devel@gnu.org; Fri, 26 Jul 2013 20:49:43 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:59220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2sha-0006qO-HD for emacs-devel@gnu.org; Fri, 26 Jul 2013 20:49:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZPn/2dsb2JhbABEvw4Xc4IfAQVWIxALNBIUGA0kiCTBLZEKA6R6gV6DEw X-IPAS-Result: Av4EABK/CFFFpZPn/2dsb2JhbABEvw4Xc4IfAQVWIxALNBIUGA0kiCTBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="19944878" 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 20:49:35 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0F52A62D9D; Fri, 26 Jul 2013 20:49:41 -0400 (EDT) In-Reply-To: <3b4713cb-5fd5-498b-b9ee-a676f0fef845@default> (Drew Adams's message of "Fri, 26 Jul 2013 15:00:03 -0700 (PDT)") 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:162185 Archived-At: > * `import': Importing a symbol into a package. Importing makes the > symbol *present*, not just *accessible* in the importing package. > If a different symbol with the same name is already accessible in the > importing package then a user-correctable error is raised: `import' > avoids letting one symbol shadow another. Sounds like CL's approach requires symbols to be present in several packages, which might require more changes than I'd like in the way obarrays and symbols work. AFAIK in Mathematica, the list of obarrays to search is just part of the current reader state, not a property of obarrays, whereas it seems that in CL the list of obarrays to search is stored in obarrays as a list of "parent" obarrays (so the list of obarrays to search is changed when we change the current obarray, whereas in Mathematica the two are unrelated). I get the impression that Mathematica's design might be fairly easy to reproduce with the current Emacs code, whereas CL's design would probably require more changes. Stefan