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: (*) -> 1 Date: Wed, 18 Jan 2023 15:27:55 +0300 Message-ID: References: <87r0vuidjc.fsf@eder.anydns.info> <87y1q1kvdm.fsf@web.de> <87h6wpkrlq.fsf@web.de> <87zgahj7h3.fsf@web.de> 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="17777"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 18 13:55:49 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 1pI7yn-0004Oa-Oy for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 13:55:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pI7yG-00053L-8w; Wed, 18 Jan 2023 07:55:16 -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 1pI7yA-00051m-H1 for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:55:11 -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 1pI7y7-0001SO-JL for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:55:09 -0500 Original-Received: from localhost ([::ffff:197.239.11.163]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010394D.0000000063C7EC2C.00001A89; Wed, 18 Jan 2023 05:55:07 -0700 Mail-Followup-To: Michael Heerdegen , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87zgahj7h3.fsf@web.de> 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:142353 Archived-At: * Michael Heerdegen [2023-01-17 22:20]: > The question of use is a valid one, we missed to answer it yet. It > wasn't clear to me that this was part of what you are asking for. Yes, that one. Why authors decided to have (*) ➜ 1 which in case of me who could delete some argument like from (* tonnes quantity) I could by mistake delete "tonnes and quantity" and result of (*) would not be detected because there is no error -- while makers (authors) of which Lisp, as I do not know where did it start, maybe in Common Lisp, maybe in Emacs Lisp, why did they decide to include it? So let me read here: > You list your expenses in a form. On six pages. You write the sum of > all expenses of any page on the bottom of the page to be able to > calculate the final sum conveniently. > > But on page 5 there are no expenses at all. What do you write on the > bottom of that page? You could write nothing, but then you might wonder > if you have forgotten to fill out that page. You could also leave a > special note "no expenses" - but in Lisp we don't have such special > values that can be used in summation. So you just write "0" onto that > page - the partial sum of no summands. That works because adding 0 > doesn't change the final result (as adding zero summands to the final > sum would) - it's the same in the case of summation: 0 is the "nothing" > of addition. Writing zero is one thing, surely I understand above. I said that I did read the identity element article, and that articles does not speak of absence of elements! It speaks that identity element is the one when added to other elements, it does not change the result. We have here case of absence of elements, not presence of elements. I understand your practical example above, I can't see relation to Lisp where author made (*) to result with 1. Of course I understand that some people say ah, there is set theory and that is identity element, but practical use in multiplication or addition I still can't find. I got clue that having that identity element was maybe helpful in other programming language like C, and then somebody started placing it in Lisp arithmetic functions, where maybe it does not have any real use. I may be wrong, but research of variadic functions kind of gives me clue to that conclusion. > Likewise, 1 is the "nothing" of products and "" is the "nothing" of > string `concat'enation, etc. I can't see that 1 is nothing for produts, but I understand what you wish to say. If (*) ➜ 1 is "nothing", adding three "nothing" yields with 3: (+ (*) (*) (*)) ➜ 3 which can't be, as nothing added to nothing can't give more than nothing. However, I do understand what you wanted to say, just with different terms. > This interpretation only makes sense when the result of (+), (*), > (concat) appears as intermediate result in some other call of `+', > `*', `concat'. By themselves the value is not always meaningful (0 > as the value of the empty sum might be meaningful, 1 as result of an > empty product less, the empty string as results of concatenating no > strings -- depends). But it allows to avoid to treat the case of > empty subsets specially. I understand in Lisp context that various functions shall give me back result, to help me with programming. But I do not see why would (concat) ➜ "" not result with errors, I would like error there to be reminded that I forgot something. Maybe before programmer wish to write which strings are to be concatenated, one can use function temporarily for testing, like (let ((result (ignore)) (my (concat)))) my) and then later this function becomes something like: (let ((result (fetch-results)) (my (concat "Result is: " result)))) my) For (concat) I can see use case as placeholder for string, so that programmer can update the function. Otherwise I don't know. Do you know use case for (concat)? Some string functions I made I want them to give me empty string instead of nil, but for concat I don't know why I would want that, I want error. For (*) I have not find use. Maybe use is in that temporary programming moments, where programmer wish to add some numbers, but did not add them yet, like following: 1. Programmer thinks of variables A multiplied by B to be multiplied with C mutliplied by D 2. But writes without variables C and D: (* (* A B) (*)) 3. Then in next step adds C and D: (* (* A B) (* C D)) Was that use case or something else that justified creation of (*) ➜ 1 Or was it just capricious thinking: "Let me add identity element, it will look more like advanced mathematics" Or was it the reason that it was maybe copied from C language which I do not know, and which maybe got much more use of functions which yield 1 for multiplication without any elements? > > OK I understand people in Common Lisp included it, and Emacs Lisp has > > it, and other Lisps. But why for example Emacs Lisp has (-) ➜ 0 but > > other Lisps not? > > That's also a valid question. > > (-) and (/) are questionable. `-' accepts one argument, so e.g. (- 7) > ==> 7. (/ 7.0) is also interpreted as value of 1/7. > > I don't care about the results of (-) and (/), these are indeed a bit > obscure IMO. I understand you have no use for those, that is what maybe had some use somewhere. If you know C language, do you think that hypothesis that it simply came from C language, could be right? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/