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: Tue, 05 May 2020 20:25:12 -0700 Message-ID: <87k11pzqw7.fsf@t510.orion.oneofus.la> References: <237fe643-c14d-5406-b35d-a30dcd42c5ed@gmail.com> <87v9lb1irk.fsf@t510.orion.oneofus.la> <87sggf193f.fsf@t510.orion.oneofus.la> <87k11q1ghn.fsf@t510.orion.oneofus.la> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="100253"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.3.10; emacs 26.2 Cc: nic@ferrier.me.uk, =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 06 05:38:47 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 1jWAtS-000Pyo-Bm for ged-emacs-devel@m.gmane-mx.org; Wed, 06 May 2020 05:38:46 +0200 Original-Received: from localhost ([::1]:35280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jWAtR-0001FU-9p for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 23:38:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWAss-0000kn-0T for emacs-devel@gnu.org; Tue, 05 May 2020 23:38:10 -0400 Original-Received: from forward101p.mail.yandex.net ([77.88.28.101]:51977) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jWAsq-0000al-08 for emacs-devel@gnu.org; Tue, 05 May 2020 23:38:09 -0400 Original-Received: from forward101q.mail.yandex.net (forward101q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb98]) by forward101p.mail.yandex.net (Yandex) with ESMTP id 1B8A22641699; Wed, 6 May 2020 06:38:01 +0300 (MSK) Original-Received: from mxback4q.mail.yandex.net (mxback4q.mail.yandex.net [IPv6:2a02:6b8:c0e:6d:0:640:ed15:d2bd]) by forward101q.mail.yandex.net (Yandex) with ESMTP id 16D65CF40002; Wed, 6 May 2020 06:38:01 +0300 (MSK) Original-Received: from vla4-a16f3368381d.qloud-c.yandex.net (vla4-a16f3368381d.qloud-c.yandex.net [2a02:6b8:c17:d85:0:640:a16f:3368]) by mxback4q.mail.yandex.net (mxback/Yandex) with ESMTP id ogpLYeAo4V-c0cuHwop; Wed, 06 May 2020 06:38:01 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneofus.la; s=mail; t=1588736281; bh=pGicSd7WUnzwWpcf/4IpL/m/92KVAlQIMG+1n6NAM4M=; h=In-reply-to:Subject:Cc:To:From:Date:References:Message-ID; b=OXMpfeHIwZQiAoRtqmHxUWgCAJqgGNqCHanQbEyD8dTy8qagX83Ut/Y0rHBgHux8k EPuGW77eU3+cBPD+HjjNfweLX/CgsZPgbUwEvmb8dqVlpKPIEa3OKETKNy8304AFKy cwolS0TtguSA8hVCkJAsZnT7M3dDWPyNzsYcgPLs= Authentication-Results: mxback4q.mail.yandex.net; dkim=pass header.i=@oneofus.la Original-Received: by vla4-a16f3368381d.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id YWA852302y-bweO4RNx; Wed, 06 May 2020 06:37:59 +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=77.88.28.101; envelope-from=vas@oneofus.la; helo=forward101p.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/05 23:38:01 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_H2=-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:249065 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Anyway, it sounds like you're describing dependencies failure. The > author of XYZ should probably say that his package requires ABC > 1.0. This is not a dependency failure. It should be possible to automatically pull in minor version upgrades that add functionality in a backwards-compatible manner (the MINOR part of MAJOR.MINOR.PATCH in Semantic Versioning). ABC 1.1 adding a new function does not break backward compatibility. > Or start paying attention to warnings. There are no warnings. The developer of XYZ developed against ABC 1.0, which did not have any warnings. In Elisp there would be no warnings period. And there would be no warnings if you assign variables instead of defining functions. > Or stop `:USE` of packages of systems whose code he doesn't > control. That is the current recommended practice in Common Lisp-land. > This is a problem that happens in other languages. I was out of the loop on R6RS, and spent the afternoon reading up on the R6RS library system to see the Scheme take on the issue. Obviously the R6RS committee recognized this problem, because it does not happen in R6RS. Their solution was to make exported bindings immutable. This is not going to work for Elisp. In contrast, Guile's module system has the same behavior and problem as Common Lisp. > Also note: I don't know what you use to "pull in dependencies", > but quicklisp in particular won't let this happen, since it works > in distributions. AFAIK MELPA does not. The real reason Quicklisp seems to avoid this problem is because it requires all libraries to build without any warnings, and redefining a function causes a warning in some implementations. Re-assigning a variable will not give any warnings and may not show up in unit tests, so this problem is still possible. That does not address the problem of an Elisp package that wants to re-define/patch some function in another package on purpose. That happens in Elisp a lot more often than it does in Common Lisp. > So the things you think happen, really just don't happen IRL. I don't know why you keep insisting this. If you don't believe me, you can ask in ircs://chat.freenode.net/#lisp This is a very real problem that has to be addressed in any Elisp namespace system. Importing all exported symbols seems like a useful and harmless operation, but counter-intuitively it can lead to worse namespace conflicts. You think you are safe to use short names because you are in your own private namespace, but then you end up unknowingly and unintentionally redefining something. -- Vladimir Sedach Software engineering services in Los Angeles https://oneofus.la