From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.devel Subject: Re: adding namespaces to emacs-lisp (better elisp?) Date: Sat, 27 Jul 2013 12:31:24 +0200 Organization: Informatimago Message-ID: <87txjg1egz.fsf@informatimago.com> 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 1374926010 13662 80.91.229.3 (27 Jul 2013 11:53:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jul 2013 11:53:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 27 13:53:32 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 1V3340-0008P0-2s for ged-emacs-devel@m.gmane.org; Sat, 27 Jul 2013 13:53:32 +0200 Original-Received: from localhost ([::1]:36672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V333z-00055t-Nw for ged-emacs-devel@m.gmane.org; Sat, 27 Jul 2013 07:53:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V333w-00053D-3F for emacs-devel@gnu.org; Sat, 27 Jul 2013 07:53:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V333u-0003O2-AJ for emacs-devel@gnu.org; Sat, 27 Jul 2013 07:53:28 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:45558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V31n5-0000VX-W3 for emacs-devel@gnu.org; Sat, 27 Jul 2013 06:32:00 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V31n3-000262-Po for emacs-devel@gnu.org; Sat, 27 Jul 2013 12:31:57 +0200 Original-Received: from amontsouris-651-1-252-173.w92-163.abo.wanadoo.fr ([92.163.83.173]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jul 2013 12:31:57 +0200 Original-Received: from pjb by amontsouris-651-1-252-173.w92-163.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jul 2013 12:31:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 78 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: amontsouris-651-1-252-173.w92-163.abo.wanadoo.fr Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:NzBjOGViMmFlNTFmMGYxYTkwNTE1Njc1MTc2OWUwYTVmYzA1YjFmOQ== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:162197 Archived-At: Stefan Monnier writes: >> * `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. Depends on what you mean by "present". Symbols cannot be interned inseveral packages. They can be interned only once, and in a single package. cl-user> (defpackage :a (:use)) # cl-user> (defpackage :b (:use)) # cl-user> (intern "AA" :a) a::aa nil cl-user> (import 'a::aa :b) t cl-user> (find-symbol "AA" :a) a::aa :internal cl-user> (find-symbol "AA" :b) a::aa :internal cl-user> (intern "AA" :a) a::aa :internal cl-user> (intern "AA" :b) a::aa :internal cl-user> The symbol named "AA" with which I played there, was interned only in the package named "A", and only once (in the first call to INTERN). Once I've imported this symbol in the package named "B', it is visible there: FIND-SYMBOL and INTERN find it. But it's still the symbol named "AA" interned in the package named "A". Notice that import may also intern a uninterned symbol into the give package: cl-user> (let ((s (make-symbol "S"))) (import s :a)) t cl-user> (find-symbol "S" :a) a::s :internal cl-user> But that's not the usual case. You can find a "reference" implementation of a CL package system in: https://gitorious.org/com-informatimago/com-informatimago/trees/master/common-lisp/lisp-reader Notice in find-symbol https://gitorious.org/com-informatimago/com-informatimago/blobs/master/common-lisp/lisp-reader/package-fun.lisp#line1318 how the notion of "present" symbol only comes in the last place before three other ways to find symbols in packages, some of them that may not be interned in any way in that package (:inherited). -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. You know you've been lisping too long when you see a recent picture of George Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin