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 10:25:45 +0100 Message-ID: References: <651bbe21-f179-730a-4f10-7dc6d27055ea@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9501"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 11 10:26:26 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 1otQIs-0002Ek-3G for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Nov 2022 10:26:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1otQIK-0007Ua-FD; Fri, 11 Nov 2022 04:25:52 -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 1otQIJ-0007UR-9H for emacs-devel@gnu.org; Fri, 11 Nov 2022 04:25:51 -0500 Original-Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1otQIH-0001Qk-6U; Fri, 11 Nov 2022 04:25:51 -0500 Original-Received: by mail-ej1-x629.google.com with SMTP id bj12so11181792ejb.13; Fri, 11 Nov 2022 01:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=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=aCelugqzuPrOAh+2peMM9Twq9fi/RiOzHTZbdHPSt8E=; b=cKW7ePtFGI5lBkZ76CcDcTILuk9ba6tYnrDOzAdHt8ubjBVocBxASc5Ldpz6T3aYcu tBdLY9gcbE8/dgOeXWGBDM1S7IcG/0lmFhWUsf9m0IbQt7SZMzRq9JjfhhIHGB5BTkIp +U+4ObJQJ6m7SmaAMBIIg0glAXqD6K4Cp6Ux9EEm79n+irClMfHgk53BFDNp/x5Rz+XO ecrAjGWxUUNSpkgk6/uhcAV2T5j7+dcIfiNeTrBnT1vXaHsc9UiuFZla5zqM4uLjTBhx wuOXI2bxCfQBM0kZSupT5QNjJ84qEwKQ0tma8U0wElBWEgyE0j9ZyHDjHkm4ZiE2GZxC oN8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=aCelugqzuPrOAh+2peMM9Twq9fi/RiOzHTZbdHPSt8E=; b=JW2O4dV6qviA6Qu+T8L7bBVpRS3tBKhBpNYL3nIp+m7IpENLPh5UfO0O1diJTvLaIL aWBpNUrfCMXwgX2IZIdz5ajITZ5qRuFpwD0YmKRRjfZH2UO9ysgvYEb4H/Aem+VLEPO2 p+fgDmmKOs4MvGULJbqATqr/4ezzTqYkkqBBnTqkCzdaljN9gmpr4fF/sAoXByPuuFIB LjuQ+28y8NC2LmUVJekNu6GnYh2ZKnlP2nshBvOuVT9pWkdZPsK8n2v9CtRFewv5bdjs JhSugHWD/bjq03EC8nt+PhI67NmiGK/uetmA65jPZD5K2bKFIiFRygC7RwFnUIn/pmGo MAhA== X-Gm-Message-State: ANoB5pnYHNyoIXJOQ3RZVHl8IWc+F0UUYPLIgZzn+f4n43pLXaH8I08M kA4sOC6AEOuSarPdA148H9y/7Zwb9GE= X-Google-Smtp-Source: AA0mqf6T7vUpUqkxprMEj4U7j2lCfjd8CwU+H4QSq7ElLrlSn4+4Dyaonp53TrCoh0ShgnoZZ6XkNQ== X-Received: by 2002:a17:906:4ad1:b0:78d:a3ca:586c with SMTP id u17-20020a1709064ad100b0078da3ca586cmr1232303ejt.287.1668158746774; Fri, 11 Nov 2022 01:25:46 -0800 (PST) Original-Received: from Mini.fritz.box (pd9e369e9.dip0.t-ipconnect.de. [217.227.105.233]) by smtp.gmail.com with ESMTPSA id b8-20020a0564021f0800b004611f5efea8sm877291edb.17.2022.11.11.01.25.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 01:25:46 -0800 (PST) In-Reply-To: (Richard Stallman's message of "Thu, 10 Nov 2022 23:34:51 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x629.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:299554 Archived-At: Richard Stallman writes: > [[[ 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. ]]] > > > What I meant was using shorthands as the basis for a general mechanism > > that somehow solves a "problem" that other languages use modules for. > > Modules in other languages work correctly because they operate on > variable _meanings_. For instance, on function definitions, on > variables, on classes, on class methods. If one name is the name of a > function and the name of a variable, the module system handles each of > those meanings separately. I must admit that I don't understand what you are referring to. Could you please give an example of a module system doing that? At first glance It sounds like visibility rules, or something, but I don't remember a language with different visibility rules for functions and variables, ATM. > It's not possible to do that job correctly in Lisp at read time, > because that precludss handling each meaning of the symbol separately. > Inevitably, CL packages are flawed compared with other languages' > module systems. The basic design decision to make them work at the > level of reading made that inevitable. We can call this the > "polyvalency problem." Well. Let me start by saying that I don't think of CL packages as modules, but, if anything but packages, as namespaces. The term module is somewhat open to definition, different languages use the term differently. Some even have both with completely different menaings, like C++. > > Module systems in other languages fit together with lexical scoping. > Lexically scoped local variables, functions, or classes don't interact > with the module system. There is no way for the Lisp reader to tell > which uses of a symbol are local. Inevitably, > > (defun my-member (elt list) ...) > > is going to inherit `elt' and `list' as symbols from the package > of standard Lisp functions, rather than the current package. I think Michael Albinus already showed that this is not inevitable in CL (shadow, shadowing-import). If one wants, you can have your own elt and car. > > The grave problem of :USE in CL packages could be fixed by replacing > it with a new construct that specifies a list of symbols to be > inherited from each other package, perhaos with renaming. I fail to understand the "grave" problem, sorry. Could you please give a more concrete example? BTW, in CL, if you don't want to use-package you can also import just the list of symbols you want. Without renaming, but I guess that could be added, if somone wants that. (I mention the idea of renaming in cl-packages.org, BTW, on the branch, but I'm still not sure it's worth it.) > Instead of > (:USE "bar") meaning to inherit all the external symbols of bar, you > would write (:INHERIT "bar" "entrypoint" ("barhack" . "hack")). > Instead of the kludgy "get an error if you :USE two packages that > clash", with :INHERIT you could avoid or fix conflicts one by one. I think what you mean can be done with import, but I'm not sure. Like I said, import doesn't have the renaming part. > > We could call this system "corrected CL packages." > It would not be compatible but it would be better. It could be compatible, at least I don't see a reason right now why it couldn't. > > This sort of inheritance could be implemented by means of shorthands, > but it could also be implemented directly in lread.c the same way > shorthands are implemented. > > The idea of CL packages is to use multiple obarrays, but that > implementation adds unnecessary complexity and unnecessary change. We > can treat names with package prefixes, such as `bar:entrypoint', as > ordinary names and put them all in one obarray. We could implement > all of the corrected CL packages system with just one obarray. > > With this approach, reading a file in package bar would transform > every name by concatenating `bar:' at the front. Let me just remark that this is a read-time solution like CL packages, so all you said above applies to shorthands as well as packages. So, that's 1:1. > > Normally name concatenation is messy and desirable to avoid, but > perhaos if done in a controlled way through a package system it would > not be messy. At least, not any more messy than is inevitable in a > package system that operates at read time. Perhaps, but I find CL packages not messy at all, TBH. Instead, I quite strongly feel that shorthand-packages are messy. And I still fail to see how shorthands address the problem a name conflicts in the first place. One obarray = name conflicts. But we've been there, I think. > > We could hide this concatenation most of the time by making print > cut off the package prefixes that are redundant in their context. See, that's what I meant when I wrote "there is no design". We could, perhaps, maybe, maybe not, hm. Why not use what's there and works? And it's not even difficult to implement or understand, at least to the degree I did, before I lost impetus. It's not even 0.01% of redisplay, for example. > I wish I could have written all this in a coherent way at the start of > this discussion. But this is an issue I dealt with 40 years ago, > before GNU, and it had become buried in my memory. It has come back > to me only gradually. No problem. > > Eli wrote: > > > Moreover, from my POV, the jury is still out on the question of > > whether we at all need packages in Emacs. "Programming in the large" > > doesn't sound very relevant to how Emacs Lisp is used. > > I share this feeling, except that I take it a bit further. In the > 1980s I thought about whether we should have packages in Emacs, and > concluded that using a naming conventions is simpler, easier and more > flexible. So I chose that. > > If CL packages were unproblematical, I'd say, "Sure, why not? We > aren't desperate to keep Emacs small nowadays." But they are > problematical, and that is a reason to choose to do without them. Please spend some effort to explain the problematic cases. > The only drawback of our current use of naming conventions is the need > to write long names in your code when referring to functions and > variables defined in other parts of Emacs. If your code refers to > many such entry points of a certain part of Emacs, maybe you want > to abbreviate those. > > If that is what you want perhaps shorthands are enough. You can > define abbreviations for the entry points that your package uses > often. > > That gives you total control over what abbreviations to use in your > package, does not impinge on any other code including the code that > defines the entry points you want to abbreviate, and it causes no > confusions once you understand what shorthands are. > > The only problem we can't avoid is the inconvenience in grep, but that > will happen with any sort of package system that permits abbreviation > of names. It is not a reason to prefer CL packages. > > You can even avoid the polyvalency problem this way. For instance, > you can define `foo-fun' as a shorthand for `find-outer-otter' the > function, and `foo-var' as a shorthand for `find-outer-otter' the > variable. > > In fact, either abbreviation _could_ be used for either the function > or the variable; there is nothing to enforce the distinction between > those two abbreviations. But if you wish to maintain that distinction > in your code, you can. I think to all of this I've already said something, so I won't bore anyone with more :-).