From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration? Date: Sat, 11 Feb 2023 13:54:10 +0300 Message-ID: References: <874jt0imh0.fsf@dataswamp.org> <87edrtqgaq.fsf@alphaville.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12714"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: Nick Dokos , help-gnu-emacs@gnu.org To: Ruijie Yu Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 11 12:08:54 2023 Return-path: Envelope-to: geh-help-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 1pQnkU-00035F-8F for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 11 Feb 2023 12:08:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQnkJ-0005O2-GX; Sat, 11 Feb 2023 06:08:43 -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 1pQnkD-0005Nk-Bm for help-gnu-emacs@gnu.org; Sat, 11 Feb 2023 06:08:37 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQnkA-0003sk-Oe for help-gnu-emacs@gnu.org; Sat, 11 Feb 2023 06:08:37 -0500 Original-Received: from localhost ([::ffff:197.239.13.175]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055D64.0000000063E77734.0000776B; Sat, 11 Feb 2023 04:08:35 -0700 Mail-Followup-To: Ruijie Yu , Nick Dokos , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142702 Archived-At: Thanks for effort. Maybe you missed my actual question. I strive to express me well. But then it become easy to deviate and go in other subjects, branching to other justifications. > > Basically function `+' deals with summation, not with addition. I thank for your Explanations are not really what I asked > IIUC, are you asking why, within Emacs codebase, there is no 2-argument > "addition" function, in addition to the variadic summation function > known as `+'? And similarly, why there is no 2-argument > "multiplication" function, in addition to the variadic product function > known as `*'? Thanks. Though I did not ask that. That is not my expression. But I can rephrase it here, in this: Checklist for fact finding: --------------------------- - Is there any practical use for (*) ➜ 1 and (+) ➜ 0 alone? - To show me the practical use example, I think that finding examples of Emacs Lisp could be useful: - where such Lisp would break if function like `*' would require 2 arguments - with tiny refactoring to make sure of the result - for example why multiply single number? Where is practical use? - And maybe we could understand it from history of Lisp. But I could not find references. > First, we can all agree that some sort of addition is needed, either > 2-arg or variadic, in order to support the most basic functionalities > like motions within a buffer and making calculations. Thanks much for attempt, but that was not my question. > Second, there should be plenty of cases (which I have not verified > within the codebase) where summing up a list of numbers is needed. If > the variadic "summation" function is not available, then each such > library (first or third party) have to either implement their own > summation function, or use something like `(cl-reduce #'add-two-numbers > input-list :initial-value 0)'. Here we are. If there are plenty of results, please find me one. > Third, if it is determined that a "summation" function is needed, then > the "addition" function is a strict subset of the summation function and > no longer necessary. Suppose we have the two functions `add' (2-arg > only) and `sum' (variadic), I hope you can agree that these two > expressions are always equivalent in terms of their results: > > (add 1 2) ;=> 3 > (sum 1 2) ;=> 3 > > Because of the reasons above, IMO, the Emacs maintainers made a consious > decision that implementing the summation function as `+' is enough for > all its use cases, and it would be no longer necessary to have a > separate "addition" function. Similarly, they decided to implement the > product function as `*'. Thanks for your hypothetical explanation, though it does not show usage of (*) ➜ 1 and none of Emacs developers told me that it is so. Though what somebody was thinking could be maybe totally irrelevant, as maybe the real reasons are in history of Lisp. I am looking for facts, not for explanations in absence of facts. Human mind tend to be perfect. In absence of information, human mind tend to create information. Newly created information is not necessarily the origin of information. > > I have excluded the purpose for `apply' and similar functions as that > > is handled properly with PicoLisp where (*) ➜ NIL -- and maybe I am > > wrong, but with all references I came closer some reasoning. But all > > the reasoning is not confirmed in Lisp books. > > I don't have an answer for why other lisp dialects have different > defaults. You see? While I am thankful for your good intention, the reasoning you brought up is contradictory to the actual Picolisp example, as you do not have answer to it. > Regarding why the default values of summation and product are 0 and 1 > respectively, here is a concrete example use case (with analysis) where > said default values are needed: > > Consider you want to sum up *all values* inside a nested list to get > a single value: > > (setq foo > '((1 2 3 4) ;=> 10 > () ;=> 0 > (1)) ;=> 1 Your `setq' above misses parenthesis: (setq foo '((1 2 3 4) () (1))) ➜ ((1 2 3 4) nil (1)) > To sum it manually, you see that this is essentially summing up the > list '(1 2 3 4 1) to get 11. For me those are three lists, and I cannot know what author intended to do with it. It is just variable assignment. I am inspecting it and following your example. > You can also write the following expression to calculate the sum: > > (apply #'+ (mapcar (lambda (lst) (apply #'+ lst)) foo)) > ;=> 11 (apply #'+ (mapcar (lambda (lst) (apply #'+ lst)) foo)) ➜ 11 Though I would never do it as you, as "empty" value I would never have in the list. Why in the first place to bring yourself in position to have empty value which you need to add? For me that is wrong programming. > Notice how you have skipped the empty sublist. In a sense, because > this sublist is empty, you *don't add anything* to the accumulated > result. Mathematically, that is the same as adding 0. Therefore, > the only natural default value for summation is 0. You are basically explaining me how the above s-expression hides the real problem that programmer missed to provide number but provided NIL instead. And the actual problem cannot be found because of it. I would think different in that case: (apply #'+ (flatten-list foo)) ➜ 11 But if I am really providig NIL values in a list, I would remove them, so that at least for me remains readable, I must have some reason for NIL values: (let* ((foo '((1 2 3 4) () (1))) (foo (delq nil foo)) (foo (flatten-list foo))) (apply #'+ foo)) ➜ 11 Of course in real life the `foo' would most probably get value from some function. I am not impressed with the example. > This analysis can also be made for the default value of product, > where when you skip an empty sublist, you *don't multiple anything* > to the accumulated result, which is mathematically equivalent to > multiplying by 1, which we can then conclude should be the natural > default value for product. Analysis did not answer to me "how it is useful". It has given explanations which are beyond the practical use of functions like (*) ➜ 1 Let us say I want to multiply some elements of a list: ;; if I need to multiply elements, I do not need outside theory but ;; there is practical reason for multiplication. There shall be two ;; elements, if not, there is error: (let ((list '(2 3))) (cond ((cadr list) (apply #'* list))p (t (user-error "Not enough arguments")))) ➜ 6 (let ((list '(2))) (cond ((cadr list) (apply #'* list)) (t (user-error "Not enough arguments")))) User error here, as why in first place did I send single argument? Why in first place I wish to multiple something with nothing? And then if I really need "2" as result, then I find it better to consciously return such result: (let ((list '(2))) (cond ((cadr list) (apply #'* list)) ((car list) (car list)) (t (user-error "Not arguments")))) ➜ 2 And what about those people who do not want to return the sole argument? (let* ((books-on-shelves (ignore 'myfunction nil)) (shelves 2) (list (delq nil (list books-on-shelves shelves)))) (cond ((cadr list) (apply #'* list)) (t (user-error "Either shelves or books missing!")))) If there is expectation of books on each shelf, then that is what I wish to multiply. There is practical use visible in the function. If I have expectation to know how many books are on shelves, I cannot do this: (let* ((books-on-shelves (ignore 'myfunction nil)) (shelves 2) (list (delq nil (list books-on-shelves shelves)))) (format "Number of total books: %d" (apply #'* list))) ➜ "Number of total books: 2" But number of total books is not 2! Because for reason that (*) ➜ 1 then I am getting wrong result! --------------------------------------------------------------- I have shown you now practical example where (*) ➜ 1 is tricky as it would give incorrect result and hide the real issue. Do you have any example from me Checklist for fact finding how would (*) ➜ 1 be practically useful? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/