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 20:00:43 +0100 Message-ID: <87siz116zo.fsf@ferrier.me.uk> References: <874nbh2z3y.fsf@ferrier.me.uk> <871u6l2ral.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374865261 9979 80.91.229.3 (26 Jul 2013 19:01:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 19:01:01 +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 21:01:02 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 1V2nGA-0007av-6C for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 21:01:02 +0200 Original-Received: from localhost ([::1]:41475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2nG9-0001sx-H3 for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 15:01:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2nFx-0001qU-Q9 for emacs-devel@gnu.org; Fri, 26 Jul 2013 15:00:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2nFu-0004bX-Cw for emacs-devel@gnu.org; Fri, 26 Jul 2013 15:00:49 -0400 Original-Received: from static.17.66.46.78.clients.your-server.de ([78.46.66.17]:59996 helo=po1.ferrier.me.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2nFu-0004bE-1m for emacs-devel@gnu.org; Fri, 26 Jul 2013 15:00:46 -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 776D5AC00F7; Fri, 26 Jul 2013 21:03:58 +0200 (CEST) Original-Received: from nics-xps (localhost [127.0.0.1]) by nferrier-Dell-System-XPS-L322X (Postfix) with ESMTP id B70AF8C0409; Fri, 26 Jul 2013 20:00:43 +0100 (BST) In-Reply-To: (Stefan Monnier's message of "Fri, 26 Jul 2013 14:18:48 -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:162167 Archived-At: Stefan Monnier writes: [resolution] >>> - 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. >> Give an example of a potential problem? >> I *think* you mean that adding new global symbols could affect >> namespaced code. But I don't think that's any different than right now. > > Here's a scenario: > - namespaced packages A and B both locally define a function `toto'. > - non-namespaced package C comes along with a symbol `toto' somewhere in > its code, suddenly causing A and B's `toto' to be global rather > than local. I don't think this is a serious problem personally. But I'm also not wedded to global-obarray-first. > 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. > IOW I think we should instead first look in the local obarray (over > which the coder does have control) and if that fails then look in the > global obarray. I am not wedded to the proposal of using the global obarray first. The rules for interning are slightly more complicated in that case: - given a string X - lookup X in the local obarray - if it exists return the symbol - else - lookup X in the global obarray - if it exists return the symbol - else - add the symbol to the local 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. But since Emacs doesn't have concurrency yet and it would be a very bad idea at this stage to add unfettered concurrency of the sort that would cause a problem here (if there were a GIL-less threads implementation for example) and the existing concurrency branch is tied to a GIL then I really don't think that is actually a real problem we need to worry about. Although I bet that's what both Guido and Matz said when they were designing the namespace bits of Python and Ruby. [import] >> Ideally that should work with some simple statement: >> ;; Package: stefan >> (import 'nic) >> (foo) >> in this example nic::foo and nic::bar would both be imported directly >> into "stefan" and after that was done the following would be true: >> (eq (symbol-function 'nic::foo) >> (symbol-function 'stefan::foo)) > > Should this equality still stand if I (fset 'nic::foo 'blabla)? > I.e. is it one and the same symbol? I guess this needs more careful specification because that would not be true of aliases. My feeling is that an import should be like the creation of an alias. >> or: >> (import 'nic :as 'blah) >> (blah::foo) >> in this example nic::foo and nic::bar would be imported under the >> namespace 'blah in the package "stefan". >> I guess this could then be a use case for trees of namespaces, so that: >> (stefan::blah::foo) >> was possible. > > Indeed, my impression is that you inevitably get to this kind > of situation, which you seemed to dislike. I personally don't find it > problematic, not even if we generalize it to some arbitrary graph, with > cycles and all. 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. Nic