From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Tue, 08 Nov 2022 23:03:20 -0500 Message-ID: References: <87r0yemgt2.fsf@rfc20.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16310"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Matt Armstrong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 09 05:04:04 2022 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 1oscJm-0003sV-QQ for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Nov 2022 05:04:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oscJ9-0002jG-GV; Tue, 08 Nov 2022 23:03:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oscJ7-0002iD-A0 for emacs-devel@gnu.org; Tue, 08 Nov 2022 23:03:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oscJ6-0007Hw-Fd; Tue, 08 Nov 2022 23:03:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=pYmUOREAdBBQO1qzMB2OPygx6A3Jm3Is3jf9TpGjTNk=; b=rmZGn/uG/+iz 1vlU8Kh//JD5f/iDXeSTOPz/daGsf7lhDgezZjZNjZzPwSunaooJqcgbdp6C03IH5TYDI4gqldYo0 cq89KQU6fonnE86KDyEDWX+RTeUop5+vfNfnmMhuRKJ3yYc62xRX1Vv1ZCQflDVE2E4H5hVKzxegl ly1oSQrpmToH6axpnwN9AhcP7i63GVWTS3qdhHXRASHIMs/Yq1LPGDxETKAN5R3qfx+2zja21VvJ8 bOhJfZETXeq8Xe97LhBj0SpYCLjmylGiYoMq7yWSv9bvZAdClncKcB4TAWQ3e7C3oYfGrCqjz9HcK r9WFO9Nr8SHF258XXd41sw==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1oscJ6-0006Uz-7H; Tue, 08 Nov 2022 23:03:20 -0500 In-Reply-To: <87r0yemgt2.fsf@rfc20.org> (message from Matt Armstrong on Mon, 07 Nov 2022 16:27:21 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299378 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > If you're talking about the :USE directive, I implemented CL packages 40 years ago -- I don't remember the details. There was a feature that let you specify, in one package FOO, "Let me omit package prefixes when I refer to symbols from package BAR." Then if BAR defines a symbol BAR:HACK, and you write HACK in package FOO with no prefix, the package system would search for a symbol HACK, find it in package BAR, and treat HACK as an alias for BAR:HACK. Is that what :USE does? If so, it would seem that :USE is the bad design I am talking about. The general idea is a nice one, but it doesn't work in Lisp. A Lisp symbol has a value, a function definition, a property list, and an identity. Since CL packages handle this by interning one symbol in multiple alists, it gangs together the symbol's slots with its identity. If the function FOO:HACK means BAR:HACK, then the variable FOO:HACK means BAR:HACK, and the propery list FOO:HACK means that of BAR:HACK, and FOO:HACK as a property name means BAR:HACK. Even examining the value of HACK with FOO selected is enough to do intern that particular symbol HACK in FOO. Making it even worse, once BAR:HACK is recorded as the meaning of HACK in FOO's symbol table (obarray), there was no way to make it mean some other symbol HACK. Suppose that package FOO says to allow reference without explicit prefix to symbols from packages ADDED and BAR. Suppose BAR has a symbol HACK and ADDED does not have one. In FOO you the HACK, and it becomes aliased to BAR:HACK. Suppose you then define another symbol called ADDED:HACK. Now the meaning of HACK in FOO has been changed. But it can't really be changed, because the obarray for FOO already contains the HACK that is BAR:HACK. This is a gross bug. We should not implement such a bug. No one ever should. We can make package systems that behave naturally and consistently. But they can't be compatible with CL packages. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)