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 17:56:50 +0100 Message-ID: <871u6l2ral.fsf@ferrier.me.uk> References: <874nbh2z3y.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374857865 23881 80.91.229.3 (26 Jul 2013 16:57:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 16:57: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 18:57:46 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 1V2lKr-0004NQ-Vv for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 18:57:46 +0200 Original-Received: from localhost ([::1]:44520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2lKr-0006Pe-MJ for ged-emacs-devel@m.gmane.org; Fri, 26 Jul 2013 12:57:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2lKA-00057Y-CR for emacs-devel@gnu.org; Fri, 26 Jul 2013 12:57:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2lK4-0001No-DR for emacs-devel@gnu.org; Fri, 26 Jul 2013 12:57:02 -0400 Original-Received: from static.17.66.46.78.clients.your-server.de ([78.46.66.17]:53205 helo=po1.ferrier.me.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2lK4-0001NK-4A for emacs-devel@gnu.org; Fri, 26 Jul 2013 12:56:56 -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 E97D9AC00F7; Fri, 26 Jul 2013 19:00:06 +0200 (CEST) Original-Received: from nics-xps (localhost [127.0.0.1]) by nferrier-Dell-System-XPS-L322X (Postfix) with ESMTP id 3DFBA8C0409; Fri, 26 Jul 2013 17:56:50 +0100 (BST) In-Reply-To: (Stefan Monnier's message of "Fri, 26 Jul 2013 11:43:40 -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:162149 Archived-At: Stefan Monnier writes: >> We had a lot of discussion recently about making EmacsLisp > > I'm not sure I understand: do you mean Emacs does not Lisp enough yet? Heh. Yeah. I dropped a word. I am going to work on blaming someone or something for that and get back to you. What I meant to say was: We had a lot of discussion recently about making EmacsLisp better. > Comments: > - "Interning a symbol with "::" in it should no longer be possible. > It should raise an error." Why not simply intern it in the > corresponding namespace? It's probably a bad practice, but Emacs is > usually not in the business of preventing bad practice. That is a good idea. I will update the document with that. I agree emacs is better off with it's laissez faire attitude. > - 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. > Currently, we're very liberal about interning in the global obarray. > Basically I think this shadowing rule makes things a bit too > automatic for something where we need more control. I disagree that's a reason not to try it. Yes, it could be a problem... but the presumption has to be that new code would use this way to namespace itself and that global pollution would therefore slow down. *Eventually* I'd expect things like the face use-case to be dealt with in some sort of namespace system. > - I'm not sure exactly how you expect importing namespaces > should/will work. I'll try and add some examples I guess. It's quite simple though, if I have a package "nic" with 2 functions: foo bar and you have a package "stefan", then you should be able to make aliases to nic::foo and nic::bar in "stefan" namespace. 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)) 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. I'm not sure about that last bit. Nic