From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: adding namespaces to emacs-lisp (better elisp?) Date: Fri, 26 Jul 2013 18:13:26 -0700 (PDT) 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; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1374887617 2050 80.91.229.3 (27 Jul 2013 01:13:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jul 2013 01:13:37 +0000 (UTC) Cc: Nic Ferrier , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 27 03:13:37 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 1V2t4i-0005n6-Vy for ged-emacs-devel@m.gmane.org; Sat, 27 Jul 2013 03:13:37 +0200 Original-Received: from localhost ([::1]:48929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2t4i-0001CR-C4 for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 21:13:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2t4g-0001CM-6h for emacs-devel@gnu.org; Fri, 26 Jul 2013 21:13:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2t4f-0008J9-CQ for emacs-devel@gnu.org; Fri, 26 Jul 2013 21:13:34 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:33303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2t4f-0008Ic-56 for emacs-devel@gnu.org; Fri, 26 Jul 2013 21:13:33 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6R1DSJv012892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Jul 2013 01:13:29 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6R1DRlh027867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jul 2013 01:13:27 GMT Original-Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6R1DQKX000985; Sat, 27 Jul 2013 01:13:27 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:162186 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. >=20 > 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. >=20 > 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)= . >=20 > 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. Please do not judge only by my paraphase. Please check CLTL2 yourself before deciding. A lot of thought - and years of practice - went into the definition of the CL package system. Wrt the consistency rules, for example, CLTL says this: "Package-related bugs can be very subtle and confusing: things are not what they appear to be. The Common Lisp package system is designed with a number of safety features to prevent most of the common bugs that would otherwise occur in normal use. This may seem over-protective, but experience with earlier package systems has shown that such safety features are needed."