From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17623: 24.4.50; incorrect example for `apply-partially' in (elisp) `Calling Functions' Date: Sat, 23 Oct 2021 16:13:37 +0300 Message-ID: <835ytn6fzy.fsf@gnu.org> References: <9fd43ff1-d6cf-4ac6-b173-2fd634f45a98@default> <871tua2o12.fsf@web.de> <1ac7ebe5-6b43-4367-beb8-df7d9f5b6750@default> <87tx75ni8k.fsf@web.de> <8338ep6kk1.fsf@gnu.org> <87pphsor8h.fsf@web.de> <83tx746fgd.fsf@gnu.org> <87ee8cyt1m.fsf@web.de> <83bl3g55t5.fsf@gnu.org> <87ilxnuczs.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7144"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 17623@debbugs.gnu.org, stefan@marxist.se To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 23 15:15:58 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1meGsP-0001dE-QI for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 15:15:57 +0200 Original-Received: from localhost ([::1]:60606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meGsM-0003xI-GZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 09:15:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meGrX-0003vB-2a for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 09:15:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51382) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1meGrW-0001rG-MP for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 09:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1meGrW-0001Cy-0a for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 09:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Oct 2021 13:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17623 X-GNU-PR-Package: emacs Original-Received: via spool by 17623-submit@debbugs.gnu.org id=B17623.16349948424537 (code B ref 17623); Sat, 23 Oct 2021 13:15:01 +0000 Original-Received: (at 17623) by debbugs.gnu.org; 23 Oct 2021 13:14:02 +0000 Original-Received: from localhost ([127.0.0.1]:34691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meGqX-0001B5-Sv for submit@debbugs.gnu.org; Sat, 23 Oct 2021 09:14:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meGqU-0001AR-Cf for 17623@debbugs.gnu.org; Sat, 23 Oct 2021 09:14:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60968) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meGqM-0000zg-HK; Sat, 23 Oct 2021 09:13:50 -0400 Original-Received: from [87.69.77.57] (port=3938 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meGqL-0000vj-4I; Sat, 23 Oct 2021 09:13:49 -0400 In-Reply-To: <87ilxnuczs.fsf@web.de> (message from Michael Heerdegen on Sat, 23 Oct 2021 14:44:39 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:217989 Archived-At: > From: Michael Heerdegen > Cc: stefan@marxist.se, 17623-done@debbugs.gnu.org > Date: Sat, 23 Oct 2021 14:44:39 +0200 > > Eli Zaretskii writes: > > > In what sense is that a contradiction? (+ 1 10) is equivalent to (1+ 10), > > so we have N = 2 arguments in the original function and M = 1 = N - 1 in > > the new one. > > No, N is described as the number of arguments the function accepts, not > as the number of arguments in someone's example. So > > N = infinity, and M = N - 1 = infinity. > > But Emacs' `1+' accepts one argument. Why does it matter? The example shows a function created by apply-partially, it doesn't say the result is exactly bug-for-bug compatible with the existing primitive. Suppose we would enhance the built-in 1+ to accept any number of arguments: would you then retract your objections? why? > 1 /= infinity. Different functions. Actually, I think the issue here is that infinity - 1 = infinity. Anyway, you are saying that, because the description in the manual doesn't pedantically cover the case of functions that can accept any number of arguments, it is incorrect? Really?? This manual is not an academic paper, where everything must be pedantically rigorous. It is a manual that teaches a language. When you teach, you sometimes use simplifications to explain a complex subject, and simplifications are always less than 100% accurate. But that doesn't make simplifications useless or invalid. Like the well-known analogy that explains gravitation-induced curvature of the space-time by describing a heavy marble ball placed on a rubber sheet (which is preposterously incorrect, if one takes the analogy apart), simplifications help people to form a mental model of what really happens that is instrumental and thus useful, even if it isn't rigorously correct. So simplifications are a useful didactic instrument, and we shouldn't be afraid of using them when they do the job. I'm sorry for this lecture, but it is my impression that you sometimes forget about this when you talk about our documentation -- this is not the first time we argue about similar stuff for similar reasons. If it will help remove your objections, we could note in parentheses that functions which accept any number of arguments will still accept any number of arguments after apply-partially. Would that be good enough for you? If not, why not? > It is a detail, but given that the preceding paragraph explains the > arity, and then we give an example that doesn't preserve arity, it's a > detail with the potential of confusion. That paragraph doesn't explain the arity. It doesn't mention that word even once. It explains apply-partially, not arity. > > I cannot disagree more. That one line doesn't make anything clear, it > > just shows the implementation. > > It does for me. We can't have both? No, because showing the implementation muddies the waters and will confuse at least some readers. So it's a net loss for a manual that needs to explain and teach. And the implementation can be easily seen anyway, it's just one keypress away. > > I object to deleting that. That text certainly helps me, so it cannot > > be useless, let alone harmful. > > Why again was saying something like "note that unlike the built-in > function this version accepts any number of arguments" rejected? It wasn't, because it wasn't suggested anywhere I could see in the discussion. I've no objections to adding this as a footnote, FWIW.