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: Tue, 17 Jan 2023 21:40:14 +0300 Message-ID: References: <87sfg9kuya.fsf@web.de> <87bkmxkpzg.fsf@web.de> <878ri1av5j.fsf@telefonica.net> 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="20786"; 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: =?utf-8?B?w5NzY2Fy?= Fuentes Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 17 19:41:06 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 1pHqtO-0005D3-KI for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 17 Jan 2023 19:41:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHqsv-0007rK-CV; Tue, 17 Jan 2023 13:40:37 -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 1pHqss-0007lE-Ol for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 13:40:34 -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 1pHqsq-0000PH-S0 for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 13:40:34 -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 0000000000103952.0000000063C6EBA1.00002E6A; Tue, 17 Jan 2023 11:40:33 -0700 Mail-Followup-To: =?utf-8?B?w5NzY2Fy?= Fuentes , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <878ri1av5j.fsf@telefonica.net> 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:142332 Archived-At: * Óscar Fuentes [2023-01-17 21:13]: > This is not about Mathematics, it is about notation, that means, > convention, that means, convenience. > > In other programming languages an expression such as "+ 2" would yield a > partially applied function: > > let f = + 2 > f 5 > -> 7 > > Lisp (or some implementations of it) went the route of "+ sums a list of > numbers." That's fine, and in that sense having (+) -> 1 is reasonable, > but there is nothing in Mathematics that says that it must be so instead > of yielding partially applied function, or simply throwing an error > message. Lisp's option is a consequence of its syntax (notation). Okay, but in C language definition of function `+' I see that if no arguments are supplied the result shall be 0, or for `*' the result shall be 1. So I see it from authoring side being something of importance, not from syntax side, as author, programmer, maybe Stallman, he could as well hande those functions with error, there was some reason why they deliberately explicitly decided to provide identity in absence of any arguments. At least I feel closer to solution after looking at "variadic functions". In the sense of minimizing errors, I have no example, is hard to understand that is the reason. In fact I need errors with many functions, as they are useful. I would not like really in my mathematical functions to get result 1 if I for example forgot to write something, instead of writing: (setq hours 10) ➜ 10 (setq interval 2) ➜ 2 (setq waiting-time 2) ➜ 2 (setq my-appointment (+ hours (* interval waiting-time))) ➜ 14 so if I write by mistake following: (setq my-appointment (+ hours (*))) ➜ 11 I would not like that mistake being there, as that would by my typo, and I need error, and not silent ignorance that I missed to write some arguments. I have given one example why and how I understand that function `*' would be more useful to yield the erorr, then 1. What I am searching is why is (*) function useful to yield 1 in some example. Do you have it? Can you maybe think of one? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/