From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.help Subject: Re: (*) -> 1 Date: Tue, 17 Jan 2023 20:04:58 +0100 Message-ID: <874jspaso5.fsf@telefonica.net> 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="26158"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:EW3D8ruk9BNUr9iky/n/ZzfUeSU= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 17 20:05:51 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 1pHrHK-0006Ws-QU for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 17 Jan 2023 20:05:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHrGj-0004Vq-Qc; Tue, 17 Jan 2023 14:05:13 -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 1pHrGh-0004UU-GG for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 14:05:11 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHrGf-0004Bq-H6 for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 14:05:11 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pHrGd-0005Un-Hx for help-gnu-emacs@gnu.org; Tue, 17 Jan 2023 20:05:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:142335 Archived-At: Jean Louis writes: > * Ó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? I think your confusion comes from an assumption that everybody else on this conversation is blind to, in the sense that nobody (I didn't read most of the thread, though) didn't explicitly stated it: + in Elisp is not the "plus" operation that we all know (the same C uses and school children use.) + in Elisp is not the binary operation, it is the summatory operator, which takes a list of arguments and returns the sum of them all. In that sense, maybe you can see more naturally that "the sum of nothing is zero." This makes possible to apply the + (summatory!) operator to any list of numbers, including the empty list. As for the * operator, it is the same case as +, with the caveat of not being so obvious that the multiplication of and empty list of numbers is 1. Here we choose convenience: as it is interesting to have all those n-adic operators work for an arbitrary number of arguments (including 0) we chose to return the "identity element" of the underlaying operation. The "identity element" e for a binary operation $ is the element that yields e $ n -> n n $ e -> n for all n. So for the logior case in your other message 0 is the identity element, as (logior n 0) -> (logior 0 n) -> n for all n. The language designers pursue convenience and consistency and take decisions based on some sense of what is "natural". Hence if we see as reasonable that the summatory of an empty list of arguments is zero (the identity element for summation) and we want for as much operators as possible to work on empty lists, we also choose to return the empty element for the underlaying operation of the operator on those cases. There are more supporting "reasons" for doing that, such as: (* 1 1 1) -> 1 (* 1 1) -> 1 (* 1) -> we want it to act as being equivalent to (* 1 1). (*) -> same.