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: Wed, 18 Jan 2023 13:46:16 +0100 Message-ID: <87h6wo9fjb.fsf@telefonica.net> References: <87sfg9kuya.fsf@web.de> <87bkmxkpzg.fsf@web.de> <878ri1av5j.fsf@telefonica.net> <87ilh4kgqo.fsf@web.de> <87zgagakh5.fsf@telefonica.net> <87cz7cka06.fsf@web.de> <87v8l49t8w.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10857"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:EoxP4NBzHk5LUaq6AjpNxRIz5V0= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 18 13:47:05 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 1pI7qK-0002cH-Vy for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 13:47:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pI7pm-0000XB-SB; Wed, 18 Jan 2023 07:46:30 -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 1pI7pk-0000WP-3H for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:46:28 -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 1pI7pi-0007Zm-CR for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:46:27 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pI7pf-0001cQ-UZ for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 13:46:23 +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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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:142351 Archived-At: writes: >> I was prompted to enter the discussion when I saw your reference to >> Mathematics. As almost every other math-related thing in computers, >> Elisp's + is a toy representation of Sigma. And then the relevant >> characteristics of Sigma for this discussion are a convention among >> practitioners, not a proper mathematical fact. > > This goes a bit deeper: whenever you have an associative operator > [i.e. (a + b) + c == a + (b + c)], > > 1. the "variadic extension" is straightforward, since you can leave > out the parentheses in (a + (b + (c + ...))) without losing info > 2. the extension to zero arguments is also straightforward *provided* > you have a neutral element, since 0 + a == a. > > This works for products, logical and, or, set union and intersection, > you name it (in mathematical logic, you often see the or/and cousins > of Sigma and Pi; in set theory likewise the union/intersection things). Yes. >> Although it is possible that the implementors were inspired by Sigma, I >> think it is more probable that they made + variadic because s-exps like >> (+ (+ 1 2) 3) are awkward and then extended the function with support >> for 0 and 1 arguments because they are convenient when defining macros. > > I think a mathematician doesn't really distinguish between "Sigma" and > just "sum". Sigma is just a notation. No magic, just maths. Sigma is often used with infinite terms, and then it no longer is a sum, at least not in the naive sense that Elisp + operates. Elisp + would correspond to the simplest incarnation of Sigma. Even a programmer can't assume that associativity and commutativity can be used on a long, finite, sum. But that's a digression. My point is that (+) and (+ n) are not supported (or, better said, appreciated) because some mathematical reason, but because they are as much convenient when writing macros as they are silly on "normal" code. It's about making easy for the programmer to do some mundane tasks, not about Mathematics.