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 14:49:54 +1000 Organization: By Dasein Message-ID: <574D41CF-B2A8-4D4A-A622-B3510F9CBC26@bydasein.com> References: <20210607033526.4c5nntohhprdkzzd@E15-2016.optimum.net> 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="24378"; 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 06:51:07 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 1lq7E9-00063n-Nw for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Jun 2021 06:51:06 +0200 Original-Received: from localhost ([::1]:45820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lq7E8-00033V-6V for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Jun 2021 00:51:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lq7DM-0002II-Bz for emacs-devel@gnu.org; Mon, 07 Jun 2021 00:50:16 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:55878) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lq7DH-0005iz-I5 for emacs-devel@gnu.org; Mon, 07 Jun 2021 00:50:16 -0400 DKIM-Signature: a=rsa-sha256; b=M2JyL1KV+X9//llt8jRuevwTswEju8EEMgKvbSOYuAfh6Qv4T0zTaUoH8xzZNwLO8S3jbDtHvfKU7u9LFuGe0GSFt1a5ZE4HgVGoU5Ul819j1qIescEUYy70VMjVVZW2/FueqXBdw4gi27u/67vy0YtYiwKf4590Wc9sZOM1szjKgTUPbdAJhcMZ5vifuSd8x83zPEeOWcKXCaJiTJF6a+3dT0nb1rcz5KCCSuS0J8YhPUQvRy8gYEOHO6LT6hY4IcFe3b1T93O1/+f5bsVrs4mRuMwItcSG30PmB5sNfvojdJYEQ/H1/hvCijxj8seK0/w/lFOh+cEPACDUES2Vlg==; s=purelymail3; d=bydasein.com; v=1; bh=Bdq4SrAcjM4CpGcbmhg995RlWlewa7fh+HqjZkTccgQ=; h=Received:From:To; DKIM-Signature: a=rsa-sha256; b=W188Ke4u3WsQQy7D0cppSeVNBAdSHm3DSGLx/EZKKGVVvylNnXHTjAByut+09xqx3Yf89xqRegMammcs4gu/pz58lWdC7s/m45dvnEuY0tyk0h9ZPJgXJkCpBccAYPaZo6Km7cieZPkBjUUc5aNAtZLazXdGmmF/m8DJF2g2weze8fSXhr/+0PT00uUQl9ySZq/VehU9+bJKWJtg2EE79nq7blpnmO3nhIUacLS7pdl1Ms2nF3aAE4NQ50sPZjlS8C/2CfDTNQ3ef8+y3qSGh+tdnqf6DZD9/H8+IrgTYyG7hEC5mYsazvePmg1nXSOGDVMD2iblllbkbUM0W/urEg==; s=purelymail3; d=purelymail.com; v=1; bh=Bdq4SrAcjM4CpGcbmhg995RlWlewa7fh+HqjZkTccgQ=; 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 -374162219; Mon, 07 Jun 2021 04:49:54 +0000 (UTC) In-Reply-To: <20210607033526.4c5nntohhprdkzzd@E15-2016.optimum.net> 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:270518 Archived-At: > On Sun, 06 Jun 2021 22:54:41 -0400, 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. Now, I *know* that someone on emacs-devel will read that and decide it means "he wants to impose or change something" so again, for that reader: please put down your pitchfork, re-read the initial email, understand that it does not suggest imposing or changing anything. What I am suggesting is that if a programmer wishes to make it abundantly and extraordinarily clear that a function/macro is internal and should never be used outside of this program, they would have this extra declaration which they could explicitly set that would provide a simple and discoverable warning to other elisp programmers. An optional addition. That's it. No one forces anyone to use it, just like we have the interactive-only declaration and no one's house burnt down. > If so, I agree to some extent, but: > - As mentioned your declaration would suffer from the difficulty of > clarifying "internal to what" since sometimes a function is internal > to a file, sometimes to a multifile package and sometimes to a subset > of a file. Of course, that can be solved by adding an extra argument > to your annotation, but: I think internal to the file is easiest but if there's some easy way to make it "internal to the package/library" then cool. But as you've already said, does Elisp have a definition of what is and isn't part of a package/library? Not really. It does have plenty of things that work file-local though. > - your annotation is placed on those functions that are internal, which > (as a coder) are those functions which I'd rather not burden with too > much extra annotations, otherwise I'll just not bother declaring them > as internal (which is what we had before the "--" convention). For you nothing would change. > - As long as the effect is just a few font-lock-warning faces here and > there, I think the problem is harmless enough (and it does point to > real misfeatures in many cases, so it would help improve the code). Cool. > Yes, currently it's a bit of a wild west because the "--" has no > effect, > but maybe it's time to impose some order on this, indeed. I am not suggesting imposing anything. Trying to retroactively impose some definitive meaning upon people's use of "--" is, as I said, the path to ruin. 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". So could someone prove how clever they are by making some sort of heuristic code to treat anything with "--" as internal? Of course. Would this have the net effect of raising false positives, confusing people, sparking endless angry emacs-devel threads, kicking your dog, and increasing bug reports? Absolutely. This is not and was never part of my suggestion. >> Also I just dislike computer heuristics. > > It's not a heuristic. Okay. > But "file" is the wrong granularity for many Gnus-internal definitions > (and same applies to all multifile packages). So what would use for > those if your declaration are only for file-local internal definitions? This is outside the scope of this suggestion. For them, nothing changes. So the objection I see is: if this explicit internal declaration were to be introduced, and say its scope is limited to the file in which it is declared, and then a programmer explicitly declares a function as internal knowing full well that this declaration means file-local, and that programmer then uses this internal function external to that file, they are rightfully triggering whatever ramifications the warnings are warning them against. See my alligator analogy.