From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Vladimir Sedach Newsgroups: gmane.emacs.devel Subject: Re: Proper namespaces in Elisp Date: Sat, 09 May 2020 18:19:40 -0700 Message-ID: <87tv0o1t8z.fsf@t510.orion.oneofus.la> References: <87ftcee7td.fsf@tromey.com> <87pnbgzdmx.fsf@tromey.com> <1225997b-648a-068d-7f6b-e1575477a0d0@dancol.org> <875zd62qy7.fsf@t510.orion.oneofus.la> <09ed390e-c735-3a7e-ecfd-504557b192a2@dancol.org> <87368a2d1a.fsf@t510.orion.oneofus.la> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="42981"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.3.10; emacs 26.2 Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Tom Tromey , Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 03:31:22 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jXaoM-000B65-60 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 03:31:22 +0200 Original-Received: from localhost ([::1]:49870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXaoL-0007aD-37 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 21:31:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34128) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXanR-0006Vc-Df for emacs-devel@gnu.org; Sat, 09 May 2020 21:30:25 -0400 Original-Received: from forward102p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:102]:44518) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXanO-0006ti-Sq for emacs-devel@gnu.org; Sat, 09 May 2020 21:30:24 -0400 Original-Received: from mxback4o.mail.yandex.net (mxback4o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1e]) by forward102p.mail.yandex.net (Yandex) with ESMTP id C82EB1D40BF5; Sun, 10 May 2020 04:30:17 +0300 (MSK) Original-Received: from iva5-057a0d1fbbd8.qloud-c.yandex.net (iva5-057a0d1fbbd8.qloud-c.yandex.net [2a02:6b8:c0c:7f1c:0:640:57a:d1f]) by mxback4o.mail.yandex.net (mxback/Yandex) with ESMTP id CvYN8t9npX-UGj0NDus; Sun, 10 May 2020 04:30:17 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneofus.la; s=mail; t=1589074217; bh=bq6h425r8X88yGCo84q+jlhuH/xy1XVZnVbIw/jLyFU=; h=In-reply-to:Subject:Cc:To:From:Date:References:Message-ID; b=PHXC8htD2c8ymQMEcappsclz7+n6C1KF60ED/2icn3REBb1aPfcJwE7pqeCe+TeOB H0Y+jlcU/VaQEFTnjf7HsgCw9j0qeMlxUynd+oC+ge+Lu/Wy7sTKp05CpmGmpYZf0S jVNgFXWI1yDCbRrpiNtEcEssZrR2c34ftN2XS0ak= Authentication-Results: mxback4o.mail.yandex.net; dkim=pass header.i=@oneofus.la Original-Received: by iva5-057a0d1fbbd8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id l7OqFU6gDL-UEDuBm8X; Sun, 10 May 2020 04:30:15 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-reply-to: Received-SPF: pass client-ip=2a02:6b8:0:1472:2741:0:8b7:102; envelope-from=vas@oneofus.la; helo=forward102p.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/09 21:30:18 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249613 Archived-At: Daniel Colascione writes: > So there are three basic operations we can support: in Python syntax, > 1) from PKG import * (exposing PKG.foo as foo), 2) import PKG as p > (exposing PKG.foo as p.foo) and 3), from PKG import foo (exposing > PKG.foo as foo). CL supports all three. I'm most interested in > supporting #2, since that's closest to existing use. The lexspace > prototype posted earlier today supports #3 and #1 (the latter via > lexspace inheritance) only, but I think we should do #2 instead, and > I think we can do it without runtime overhead. Before I write anything else, I have to call attention to a fact you might already be aware of: Python cannot do code re-loading reliably, because depending on which of these 3 ways a function is imported, the new definition might or might not be seen. This is a really good example of the way that namespace systems can have unintended consequences, and why we have to be careful designing one for Elisp. #3 is ok, because that way you know exactly what you are importing, and will not get any surprises if PKG exports another definition later. Most use cases want a single #1 to pull in the language that you are working in (in Common Lisp, this would be the "COMMON-LISP" package). As I pointed out in another sub-thread, this can be used to advantage if you version Elisp namespaces to major Emacs versions (elisp29, elisp30, etc.). It is a lot easier to support backwards compatibility and make major changes to Emacs that way. The only problem is retrofitting this on top of the global namespace. The global namespace is going to have to be a fallback for all symbol lookups. Existing libraries also need to have their declared exports put into the global namespace with their chosen package prefix and appropriate autoloads, to be compatible with packages that do not use namespaces (advice/redefinition is going to have to do the appropriate thing in both places, and dynamic bindings have to be shared!). Modifying internal functions is already a gamble on updates, so I think it is ok to tell people "you need to access this internal function with a namespace qualifier because the package now uses namespaces." The reason #1 becomes a problem is if you do it two or more times. This is akin to "namespace multiple inheritance." This is different from multiple inheritance in OO because it is not transitive (you do not want to import the dependencies of the package you are importing!). -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la