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: A prototype for a binding based approach to proper namespaces Date: Sat, 09 May 2020 15:52:29 -0700 Message-ID: <87zhag202a.fsf@t510.orion.oneofus.la> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="106829"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.3.10; emacs 26.2 Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 01:00:58 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 1jXYSn-000Rga-Lu for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 01:00:57 +0200 Original-Received: from localhost ([::1]:60586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXYSm-0008NE-MI for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 19:00:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXYS8-0007uM-Vr for emacs-devel@gnu.org; Sat, 09 May 2020 19:00:17 -0400 Original-Received: from forward105j.mail.yandex.net ([5.45.198.248]:60778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXYS6-00013c-Gx for emacs-devel@gnu.org; Sat, 09 May 2020 19:00:15 -0400 Original-Received: from mxback22o.mail.yandex.net (mxback22o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::73]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 39BDCB2012E; Sun, 10 May 2020 02:00:08 +0300 (MSK) Original-Received: from sas1-26681efc71ef.qloud-c.yandex.net (sas1-26681efc71ef.qloud-c.yandex.net [2a02:6b8:c08:37a4:0:640:2668:1efc]) by mxback22o.mail.yandex.net (mxback/Yandex) with ESMTP id A7A4qOqAMm-077K0bGc; Sun, 10 May 2020 02:00:08 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneofus.la; s=mail; t=1589065208; bh=2gapVnvgLLIXmGP4QlOMNieMWJjFu5rsImsljyYQmk0=; h=In-reply-to:Subject:Cc:To:From:Date:References:Message-ID; b=YgauZ3pb3JU4PrbJ/0sOIHvvqZFK1PmRtD5SWQ0buOLKi5IeuEOI/eaz3A0FPXI8f 36ikAMgFioQOBjPYmKYDJpEImgWeRLFnooXmrE5P4g+Qlx4YZ2vdiAu5eIjG0iQms/ Pam2QthHH7YsyXUa0cw0bsnqkM6pq/qC+1CR0o70= Authentication-Results: mxback22o.mail.yandex.net; dkim=pass header.i=@oneofus.la Original-Received: by sas1-26681efc71ef.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 2p3MyIeArx-053iSi0F; Sun, 10 May 2020 02:00:06 +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=5.45.198.248; envelope-from=vas@oneofus.la; helo=forward105j.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/09 19:00:08 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:249595 Archived-At: Hi Andrea, The implementation reminds me of how Corman Common Lisp implements thread-local dynamic binding, minus the chaining of bindings. Here are some comments on the document: > potentially could open the door to other interesting options like > namespace versioning. Different version of the same library could > then coexist loaded. This is an interesting idea. In R6RS, library definitions and imports include optional version information, but if you look at section 7.9 of the R6RS rationale document: > Implementations are encouraged to prohibit two libraries with the > same name but different versions to coexist within the same program. > While this prevents the combination of libraries and programs that > require different versions of the same library, it eliminates the > potential for having multiple copies of a library's state http://www.r6rs.org/final/html/r6rs-rationale/r6rs-rationale-Z-H-9.html So it seems that the use of R6RS library version numbers is intended for dependency management only. I think the same reasoning applies to Elisp. For example, a package could change the type of arguments it accepts for a customizable variable. This recently happened in a few places in mu4e. Or a change in the data structures used in some resource outside of the namespace, such as a file somewhere on disk. But versioning information could be used for dependency management if shared between namespaces, require, and package.el -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la