From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Sat, 12 Nov 2022 09:17:11 +0000 Message-ID: <87zgcw5y7c.fsf@gmail.com> References: <651bbe21-f179-730a-4f10-7dc6d27055ea@gmail.com> <878rkh7ep6.fsf@gmail.com> 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="1880"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Richard Stallman , Andrea Corallo , Eli Zaretskii , emacs-devel To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 12 10:16:59 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 1otmdH-0000Ig-5k for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Nov 2022 10:16:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1otmch-0004WX-0Z; Sat, 12 Nov 2022 04:16: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 1otmcS-0004W0-N6 for emacs-devel@gnu.org; Sat, 12 Nov 2022 04:16:08 -0500 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1otmcN-000237-NR; Sat, 12 Nov 2022 04:16:06 -0500 Original-Received: by mail-wm1-x336.google.com with SMTP id p13-20020a05600c468d00b003cf8859ed1bso4505971wmo.1; Sat, 12 Nov 2022 01:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uPorvx4FoeP0+B6MpxGPKQfQrgD/dq4nDERsL7FnAt8=; b=c8vW6l+B75Pdy8IWYES7Kx4/eJKV4C9XjL8CzQ/Fl2c4R/5UIdT0DuojAGFWcmdqkq /blVk49kJn8Q2dc3eneRqJNNd8renPBIzr/ZMiupEU8+czPcPcTzxqV8JstoXMGsyLLc FWYXKu0tQ4Pfva936b7GsPJlN5WROSucHZ0gad9jQTzOSCqBJyVvoMfaFkd0MOEqjOXY KCpbA+LeMX2eVXj3Npl3s3odQJdQFgKUVBzkBqUALEjPUod2A+Tv7naS3SCV4U2VZcFB +MgSvd9N7B2/w0xj6FuasElhVBHqaeUCA0FW7hd6dAeJOmsjp0riyAZgqgQUkhJ3pLYM 0rTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uPorvx4FoeP0+B6MpxGPKQfQrgD/dq4nDERsL7FnAt8=; b=xBH9QLgOx6FnkYKB1iEyRL6uG8bY0H8VrOnD4EOKrw/PoBMpZ5UMJQ+YS5/CDJYQYm hhFUot4APmdDUL297HelQ3vp4yBjqJTSzZeFd1pBPPsG1znwf0fv5F1cNgpGCRpMGHkf FkBEYgZGwWgOaIRdgaGtrdZ04EdExM+Aiaca0Fc+90QTMkhlf0Aw7vPX/+KqTHbeqiVQ KhiVXKFKZ/MDESeklSOTcxOiBXCYscCJYOM7Bd2wmjYtULc8y2OmM1XTv28dbMwSTUAf EoeNck35fhjHB/+7FqB73tDdYnis0op5v3f13mo5w6VYs09YVOWxxTiNWZgJtCePJgaL N/zg== X-Gm-Message-State: ANoB5plWAdzp1oE023zhvo+g1kskPTmwO0HNxwK/29Y3P1x0yOBbPSVc C2XApe/tE4qRFlf6yxgvhmRMso9iJIM= X-Google-Smtp-Source: AA0mqf5B1eVfQXKGK8gi+qDsXiBht8XN3UpODWyWw/SVXmGBnyO9EgiapUX62NPmojkzH1q5i/n/oA== X-Received: by 2002:a05:600c:43d2:b0:3cf:92cc:9e5f with SMTP id f18-20020a05600c43d200b003cf92cc9e5fmr3435905wmn.181.1668244557739; Sat, 12 Nov 2022 01:15:57 -0800 (PST) Original-Received: from krug (87-196-81-1.net.novis.pt. [87.196.81.1]) by smtp.gmail.com with ESMTPSA id bi19-20020a05600c3d9300b003c6c1686b10sm10928213wmb.7.2022.11.12.01.15.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Nov 2022 01:15:57 -0800 (PST) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Fri, 11 Nov 2022 16:12:05 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x336.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:299635 Archived-At: Gerd M=C3=B6llmann writes: >> Anyway, I can't understand how the presence of shorthands can negatively >> impact CL packages. If co-existence is complicated (but is it?) it >> doesn't seem hard to make either shorthands or CL-packages a noop in in >> files that prefer one of the systems. For example, the reader can just >> throw away any shorthand info altogether as soon as it detects that >> CL:*CURRENT-PACKAGE* (or whatever equivalent you're envisioning) is not >> the default one. Or CL:IN-PACKAGE can just error out if it detects that >> read-symbol-shorthands is non-nil. > > If I implied that then I have to apologize. I meant to convey that No need to apologize at all :-)=20 > (a) I haven't done any experimeent whatsoever with shorthands in > feature/pkg because I set that delibaretly out-of-scope. One has to > draw a line somewhere. > > (b) I can't exclude the possibility of non-backwards-compatibility due > to the use of shorthands. At least they way I've been doing things in > the branch. It's also not proven to be incompatible. It's unknown. You can make some tests. If one goes boom, then we'll know for sure. If none go boom, well, it's a good indication, but it's very hard to prove a negative. I mean, can you really prove Emacs didn't cause the Hindeburg?? > (c) I might have an idea how do things differently to achieve > backwards-compatibility. To what extent that works, or if it works at > all, I also don't know, and likely won't find out any time soon. > >> But even if the read logic didn't do that, and considered the two >> systems at once, I'm still not sure there would be any ambiguity. > > From my point of view, the gist of the matter is > backwards-compatibility. That's the pain part. To be honest, I don't think you should focus effort on this. Just declare shorthands out of bounds when CL packages are used, and then go move on with your project. IOW proclaim that shorthands only ever worked in the default package and will continue working only in the default package (the main obarray). This is absolutely true and saying so is not breaking backward compatibility. What's more, no-one will ever request that shorthands work outside the main package, where they are useless anyway. It would solve any compatibility packages. In practice, this can be as simple as putting some check for a future CL:*CURRENT-PACKAGE* somewhere in the current shorthand-consulting reader. Jo=C3=A3o