From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Paul W. Rankin" via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: declare function/macro private Date: Mon, 07 Jun 2021 16:45:09 +1000 Organization: By Dasein Message-ID: References: <20210607033526.4c5nntohhprdkzzd@E15-2016.optimum.net> <574D41CF-B2A8-4D4A-A622-B3510F9CBC26@bydasein.com> Reply-To: "Paul W. Rankin" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1366"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Purely Mail via Roundcube/1.4.10 Cc: Emacs-Devel List To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 07 08:46:53 2021 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 1lq92C-000AZc-Ev for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Jun 2021 08:46:52 +0200 Original-Received: from localhost ([::1]:60920 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lq92B-0003ZT-DB for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Jun 2021 02:46:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lq90x-0002BW-FK for emacs-devel@gnu.org; Mon, 07 Jun 2021 02:45:35 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:59820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lq90u-00018q-GN for emacs-devel@gnu.org; Mon, 07 Jun 2021 02:45:35 -0400 DKIM-Signature: a=rsa-sha256; b=gsBYB0kbLqKLZb+nSXqaxb2FhhJFAS2lsM9/fRfoxDWxndIEPjZAeJMmYsdNJoNKQGbbDpEIqvRcHVD5PRiJM/rex7ew2Dt3j9STSFtvm6Djjq+0ZwblUgSj5QmwXpHS//7zgFw+5zxXup5U+YBwzJmRnbpWw/XYMwrEMkl0ynKE09L7Nbi2QOi5EegWqn9CzgymNWyOELqEX5jgpTjGS1nHpVJ4ITNwUsCFGglsyNFcZxY2wMqBVXTDSjwRkIG0VqKxciT15jiLSyGPwyb1rZLbREHn9MSkhPOnGpFBxbF6gcyud8mC7RsJSv2DNOoX8PKiNkuzdgugK7F1SyNfkw==; s=purelymail3; d=bydasein.com; v=1; bh=P5/VHr1Xd7j8rD/D99pbzJORrd8JI2t9W6NM89p25d4=; h=Received:From:To; DKIM-Signature: a=rsa-sha256; b=rEkzGEhelUMBNzeL0NPBM2VOMvwodN9Poz/idS2HYvmndRhpNw85hiCHpUL6j6j0j65tOy2OwOe10cI/AtkXPrT7tyZZaVZmz02jlEhP5QVbW1J5XGxJva8JTbpx9ysUldtu2xa91rMJh42u2yVPBVxCpowL5YO7OyvUYG8YcHZGiHoRZKvSmrJD6csru8v9Rtgm9cy4tRgeJdx6Vv3mVFeWgJklVxP5EYfuo67WgrHTEznqqfpaxuecks5eRsaagSGzixn2+WcqFs7my+LFsBya05kzrnGZdZGDu14T5W5jkqLx/Kv1bXwZlKx+El2En8h+pGah9LfgoZSQTMWDKw==; s=purelymail3; d=purelymail.com; v=1; bh=P5/VHr1Xd7j8rD/D99pbzJORrd8JI2t9W6NM89p25d4=; h=Feedback-ID:Received:From:To; Feedback-ID: 791:353:null:purelymail X-Pm-Original-To: emacs-devel@gnu.org Original-Received: by ip-172-30-0-164.ec2.internal (JAMES SMTP Server ) with ESMTPA ID -571502075; Mon, 07 Jun 2021 06:45:09 +0000 (UTC) In-Reply-To: X-Sender: pwr@bydasein.com Received-SPF: pass client-ip=34.202.193.197; envelope-from=pwr@bydasein.com; helo=sendmail.purelymail.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, SPF_HELO_PASS=-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.23 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" Xref: news.gmane.io gmane.emacs.devel:270521 Archived-At: On 2021-06-07 15:59, Stefan Monnier wrote: >>> No, I'm still wondering what it is you find to be different. >>> My current guess is that you fear that "--" has currently been used >>> carelessly and imposing a more "structured" meaning to it after the >>> fact >>> will hence introduce problems, whereas your declaration would come >>> right >>> away with an associated "precise" meaning. >> I was *so sure* I had made this clear having said it four times, but >> okay: >> I do not wish to impose or change anything. > > I'm not sure which part of what you quoted made you think that I think > you with to impose or change anything (other than add a new > declaration, obviously). Cool. This was not necessarily directed at you individually. I just want it be be crystal clear the limited extent of what I'm prepared to suggest/defend. Wording-wise, I wouldn't consider something like this a "change" in the sense of something existing that gets replaced with something else, but yes it's a "change" in the sense of something added. > From that stand point the two discussions are orthogonal. They only > interact to the extent that they provide similar features so they are > somewhat redundant. In a way yes. From (info "(elisp) Tips for Defining"): `PREFIX--...' The variable is intended for internal use and is defined in the file `PREFIX.el'. (Emacs code contributed before 2018 may follow other conventions, which are being phased out.) So right now it's just a tip that is supposed to communicate the author's intent. This is why I don't buy the idea that anyone could have used internal functions in multi-file packages -- because all they've done is followed a tip to communicate intent. >> Trying to retroactively impose some definitive meaning upon people's >> use of "--" is, as I said, the path to ruin. > > I disagree. I've been in the business of slowly changing ELisp coding > style for more than 20 years now, and while I'm not sure that what I've > proposed here to do with "--" would work well, I'm pretty sure it would > not be a path to ruin. Okay perhaps not. >> Others do not necessarily know what I know, i.e. while I may know that >> "--" >> is a convention that means "internal" in Elisp, other people may not >> (or >> likely do not). I suspect many programmers use it just because they've >> seen >> it used in other packages. And given that Elisp does not have any >> explicit >> definition of what is "internal" it would make little sense to impose >> one >> now and say "oh well that's what we meant all along". > > I think most people who don't know better won't see any difference > either after we'd introduce the new rule. Or if they do, they'd then > learn about it and either adjust their code or ignore the warning. > >> This is not and was never part of my suggestion. > > Of course not. That was my suggestion. I just really do not want to be caught defending the "--" idea against the hordes. I hope the rest of the thread can please consider that a wholly separate idea. The idea of a `(declare (internal ARG))' seems an easier sell because it won't affect anyone who doesn't explicitly use it. It seems to open more possibilities for font-locking as Lars mentioned, and for generating info in the help buffer. Further to that, you could provide "levels" of how internal something should be treated, e.g. (declare (internal t)) <- basic warning (declare (internal "use `foo-public' instead.")) <- warning with hint (declare (internal 'strict)) <- compiler signals an error, computer catches fire