From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nic Ferrier Newsgroups: gmane.emacs.devel Subject: Re: adding namespaces to emacs-lisp (better elisp?) Date: Fri, 26 Jul 2013 22:43:25 +0100 Message-ID: <87mwp90zgi.fsf@ferrier.me.uk> References: <874nbh2z3y.fsf@ferrier.me.uk> <871u6l2ral.fsf@ferrier.me.uk> <87siz116zo.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374875025 15973 80.91.229.3 (26 Jul 2013 21:43:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 21:43:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 26 23:43:45 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 1V2pnZ-00045T-8L for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 23:43:41 +0200 Original-Received: from localhost ([::1]:54303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2pnY-0000lo-Sc for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 17:43:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2pnT-0000lL-Il for emacs-devel@gnu.org; Fri, 26 Jul 2013 17:43:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2pnO-0008Fw-FH for emacs-devel@gnu.org; Fri, 26 Jul 2013 17:43:35 -0400 Original-Received: from static.17.66.46.78.clients.your-server.de ([78.46.66.17]:41744 helo=po1.ferrier.me.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2pnO-0008Fi-7g for emacs-devel@gnu.org; Fri, 26 Jul 2013 17:43:30 -0400 Original-Received: from nferrier-Dell-System-XPS-L322X (140.35.155.90.in-addr.arpa [90.155.35.140]) by po1.ferrier.me.uk (Postfix) with ESMTP id 77E71AC00F7; Fri, 26 Jul 2013 23:46:43 +0200 (CEST) Original-Received: from nics-xps (localhost [127.0.0.1]) by nferrier-Dell-System-XPS-L322X (Postfix) with ESMTP id DF2258C0508; Fri, 26 Jul 2013 22:43:25 +0100 (BST) In-Reply-To: (Stefan Monnier's message of "Fri, 26 Jul 2013 16:59:58 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 78.46.66.17 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:162178 Archived-At: Stefan Monnier writes: >>> Note that instead of "non-namespaced package C", we could have some >>> package which uses symbols as "uniquified strings" and which uses the >>> global obarray for it and might occasionally intern `toto' in the course >>> of its normal execution. >> Again, it only matters if it's a non-namespaced package that does it. > > No, a namespaced package can just as easily call `intern'. > But even if you can hope the a namespaced package wouldn't do it, the > non-namespaced packages are very numerous and do all kinds of nasty > stuff and we have very little control over them (e.g. they're not > bundled with Emacs). If a namespace package calls intern the symbol is interned in the private obarray. >> The only problem I see here is the possibility of problems with >> concurrency. The whole operation above would have to be atomic and it >> involves lookups in two separate data structures. > > That sounds like a very remote problem to me. And if/when concurrency > is added it doesn't seem like it should be difficult to make it > work reliably. Agreed. >> My feeling is that an import should be like the creation of an alias. > > Function alias? Variable alias? > I don't much like the sounds of it. I'd much rather make sure they are > simply one and the same symbol (I guess "symbol alias"). Ok. Well I think I'm going to go through that in much more detail and update the proposal. >> It's not that I don't like it per-se. I just want this to be easy to >> implement in the first instance. If the implementation gets more >> difficult later I have no problem with that. But initial low cost is a >> good thing. > > I'm not sure why the implementation should be difficult. `intern' would > "simply" need to parse the string into a list of elements (separated by > "::" or whatever), then lookup the first element in the obarray, which > should contain another obarray, then lookup the second element in that > obarray, etc... until the last element which is handled "in the old > way". It would clearly be more work to add the extra indirection to allow namespaced namespaces than to have one level. But I'll spec it out more closely. Nic