From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Fri, 11 Nov 2022 16:12:05 +0100 Message-ID: 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="6750"; 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: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 11 16:12:32 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 1otVhm-0001aN-R4 for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Nov 2022 16:12:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1otVhZ-0003dJ-GR; Fri, 11 Nov 2022 10:12:17 -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 1otVhX-0003c5-Ul for emacs-devel@gnu.org; Fri, 11 Nov 2022 10:12:16 -0500 Original-Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1otVhV-0004j5-Tj; Fri, 11 Nov 2022 10:12:15 -0500 Original-Received: by mail-ej1-x635.google.com with SMTP id 13so13277321ejn.3; Fri, 11 Nov 2022 07:12:12 -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=MzgKUkAEBr16TR84QoNunYXcZYSq4NMbCk5Y7kGfkt8=; b=dKCd5T9EEhECoRykS+2bPy3K1pBZ+UH5p/qdwd7uFIHscw6qAl7GdjPzQ2DmgA0brD 9OmeYc1lzjfTwRHzhbeUkZUUj3NP2F6b9j9xyiFDN6cds2fmjX+ukntADV2KoGkkO2cm nzbih14eCVV28ctQyQHSKVe8FsHxk9RnuoCXW5U3oPoxzgmeC3tbdAUgwg93zNOi3Pha /MIB/FgGvp8jLm3yGn51d8N41OMrNvPfJ5pXIQ/bLrowElHqneQYZz6EHIWF+q1fSKlM Vv9vcy5fkKHapcR1DkVPv8jzQcAoYanSgx+vryojbX0gcVp0548pTenFivDKMKxZq4wD cODQ== 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=MzgKUkAEBr16TR84QoNunYXcZYSq4NMbCk5Y7kGfkt8=; b=s3q4bP9aXBkefFxg7mEjDlLBjYrXegsiMSPVFO+cUXHfTqzWTlMP4me8JB/HVL3PJ/ mZyT93RoFaOT6ZwFyUKnHTHIa1PAfzetrCWAYVis48/ZC5Xk7XNmNrK2jOAg5YjupY42 rtCqs6unf4kxLRQq+QoSgNeOVchBzZAouHQbHM4+Vu69K0FWBS/O7jJbrWkrS3MCrncn YIxrHQUfWC2r1BIVXT+QtVsQW0uCUjFW01qJ0YwOG80txIZbs170FBf/YKOtklGdh+LH tVaxgablRoHma+pH07WqEMrWlsHKQsHB0K0omhgJJfEtJ/kEhSsY9OjagGue26vnYWiQ Czew== X-Gm-Message-State: ANoB5pkEUXd+C7z2Gm8k9rlR28+WFrd2Dm8AfpjAQ8snhVCYQGuaGMSD Cfqu8khGMzHHLQkJyINmEJg9AC2d+kI= X-Google-Smtp-Source: AA0mqf5yp26UtGm0r6uovse79BFKIUEiAQxxkMwLHJDSjKJBboUjzWrVRQ0VO2lZgU0p+vspvCXLCg== X-Received: by 2002:a17:906:3a55:b0:78d:f2d8:4623 with SMTP id a21-20020a1709063a5500b0078df2d84623mr2207858ejf.274.1668179529403; Fri, 11 Nov 2022 07:12:09 -0800 (PST) Original-Received: from Mini.fritz.box (pd9e369e9.dip0.t-ipconnect.de. [217.227.105.233]) by smtp.gmail.com with ESMTPSA id qq18-20020a17090720d200b00773f3ccd989sm972530ejb.68.2022.11.11.07.12.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 07:12:08 -0800 (PST) In-Reply-To: <878rkh7ep6.fsf@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Fri, 11 Nov 2022 14:23:17 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::635; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x635.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:299573 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > So you seem to be somehow lamenting that shorthands is a namespacing > system! :-) Hehe :-). No, I wanted to disagree with Richard saying that there is no change of semantics at all. You know--somone being wrong on the Internet and so :-). > > 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 (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. (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. In the case of packages, how to load/execute code from Emacs <=3D 29 in an Emacs having packages. In Emacs <=3D 29 we find one set of rules, like allowed symbol name constituents, the behaviour of intern/intern-soft/symbol-name, when used with symbol-concing, what is a keyword and so on. In Emacs with CL packages, some of these rules are changed, apparently in a way that mostly works, i.e. I can run it with unchanged packages compiled for 29. The situation when using shorthands is only insofar different, that I didn't try to cope with it. I only have kind of an educated gut feeling, if something like that exists, especially with dynamically-bound read-symbol-shorthands that this is, let's say, difficult. Or maybe it isn't. I don't know. Someone has to invest the time to find out. > > Regardless, if/when CL packages ever make it to core (I hope they do, of > course), I can't see why someone would want to continue to combine their > use with shorthands. The convenience aspect of shorthands would be > completely dwarfed by CL packages. Some will, some won't, and some maybe want to use both. Once it's there it's there, which means we have to cope with both at the same time. Ce la vie :-).