From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Mon, 07 Nov 2022 16:27:21 -0800 Message-ID: <87r0yemgt2.fsf@rfc20.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?utf-8?B?TcODwrZsbG1hbm4=?= , emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 08 01:28:41 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 1osCTn-0008Ja-Tz for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Nov 2022 01:28:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osCSo-0001kc-HH; Mon, 07 Nov 2022 19:27:38 -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 1osCSm-0001js-S6 for emacs-devel@gnu.org; Mon, 07 Nov 2022 19:27:36 -0500 Original-Received: from relay10.mail.gandi.net ([2001:4b98:dc4:8::230]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osCSf-0001as-9W; Mon, 07 Nov 2022 19:27:36 -0500 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 9AC0D240006; Tue, 8 Nov 2022 00:27:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1667867245; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tKG8rGPGd2iiXaCxP9jsNDeRhHHXVNGLhZNvbiTdZuc=; b=p13MAyabYVgRzsxwjCeZTu/dYiH6b5jtKbTxwlD71B8YCdFGSQdt7Y0zP4o8fB8AQLS2s4 tt9G7btoLPWv+azUEwx5xJcoJ8+ul+i5BEpC2do7F/Lpnm1R+DvSyHqIR7gPc0jokTlbpX eZwTOso4mKbQv4lTudYCGwsOelQWYwdT9qTZCX6Gun1jqejYLSvc7RGCE42p6QsKhpwsQi 9xyKfFxxO8WI0Lnqy6TwERd5aTJWOVtEY4C5yEBQi46ROJLfCaDpVyAWakNO2pCxSzUcll v2ZCQ19Y5DM3THXanke9WrcefcZPyTG/34Dfj6h7qfDEl26BwAYPcyH1AauNrA== Original-Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1osCSX-000iSP-2u; Mon, 07 Nov 2022 16:27:21 -0800 In-Reply-To: Received-SPF: pass client-ip=2001:4b98:dc4:8::230; envelope-from=matt@rfc20.org; helo=relay10.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:299309 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Sat, Nov 5, 2022 at 3:13 AM Richard Stallman wrote: > >> If CL packages still have the misfeature of searching a list of >> packages for one that has a symbol 'foobar' in it, and deciding what >> `foobar' in your code means based on that, then they are inexcusable >> bad design and we must not implement them. >> >> If they no longer have that misfeature, maybe they are ok. > > If you're talking about the :USE directive, you don't have to employ > it: it's not mandatory for CL packages to be immensely better. But > it's very useful and convenient in specific, well-understood > situations. If you're talking about something else, I don't know what > it might me. My understanding is that Richard is concerned about ambiguities, perhaps not even flagged as errors at load time, that occurred in a version of CL packages he implemented or otherwise worked with in the past, but that may no longer occur in Common Lisp implementations conforming to the newest standard. I believe he described the "misfeature" he is concerned about more clearly in https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg02165.html. There, I think Gerd made the convincing argument that the situation is acceptable in current CL standards. If so, then Richard may be closer to a "maybe they are ok" judgment about CL packages than he has been in decades. ;-)