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: Fri, 20 Jan 2023 11:01:52 +0300 Message-ID: References: <87y1q1kvdm.fsf@web.de> <87h6wpkrlq.fsf@web.de> <87zgahj7h3.fsf@web.de> <87cz7c9c9e.fsf@telefonica.net> <87o7qu8o2c.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="40376"; 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 Fri Jan 20 09:30:40 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 1pImnH-000AHN-4I for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 20 Jan 2023 09:30:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pImmi-0007v8-16; Fri, 20 Jan 2023 03:30:04 -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 1pImmg-0007pm-08 for help-gnu-emacs@gnu.org; Fri, 20 Jan 2023 03:30:02 -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 1pImme-0005iA-0y for help-gnu-emacs@gnu.org; Fri, 20 Jan 2023 03:30:01 -0500 Original-Received: from localhost ([::ffff:197.239.15.2]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103A90.0000000063CA510A.000027E3; Fri, 20 Jan 2023 01:30:01 -0700 Mail-Followup-To: =?utf-8?B?w5NzY2Fy?= Fuentes , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87o7qu8o2c.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:142446 Archived-At: * Óscar Fuentes [2023-01-19 19:53]: > > That explanation sounds like neglect in programming. > > That's your personal opinion. Quite a few programmers think that not > using strict strongly-typed, statically-typed languages is > irresponsible, and see, here we are dicussing Lisp. > > BTW, do you consider support for more than two arguments on + and * also > a neglect in programming? That is quite alright because: 2 + 3 + 4 = 2 * 3 * 4 = is just fine and useful for human. People add numbers, multiply numbers. What is also useful is when factor is missing, for debugger to raise the error. Multiplication with single argument like here: (* 4) ➜ 4 Should be prevented by simply resulting with that single argument, instead of trying to multiply what is not necessary. (let ((my-random-numbers (make-list (1+ (random 3)) (+ 2 (random 5))))) my-random-numbers) ➜ (4 4 4) ;; I do not know how to make better example for `plus' function which ;; require 2 addends (defun plus (addend-1 addend-2 &rest addends) (eval `(+ addend-1 addend-2 ,@addends))) (plus) -- error (plus 2) -- error (plus 2 2) ➜ 4 (plus 2 2 3) ➜ 7 Thus in some complex operation, programmer better test what arguments are given to `apply'. (let ((my-random-numbers (make-list (1+ (random 3)) (+ 2 (random 5))))) (prog2 (message "List: %s" my-random-numbers) (cond ((cadr my-random-numbers) (apply #'plus my-random-numbers)) ((car my-random-numbers) (car my-random-numbers)) (t (warn "Did not get 2 factors!"))))) ➜ 6 in cases where radnom number of factors is given to multiplication, it seem to me better to take care of arguments and not at all `apply' or `reduce' as that way programmer can hardly find out what was actually the case. The explanation that (*) is made only for programmers to minimize errors sounds rationalizing. I believe there is some use of (*) which is probably in some old book or sources of Lisp in first place. > > ~$ pil > > : (*) > > -> NIL > > : (+) > > -> NIL > > : (apply '* '(2 3)) > > -> 6 > > What's the output of > > (apply '* '()) > > in PicoLisp? Emacs ----- (apply '* '(2 2)) ➜ 4 (apply '* '()) ➜ 1 PicoLisp -------- (apply '* '(2 2)) ➜ 4 (apply '* '()) -> NIL That is my natural expectation. I find it useful to have NIL as that would raise my attention that I have not provided arguments to multiplication. > > If you have some reference to that reasoning that (*) is related to > > `apply' from language designer, let me know. > > I have no such references, nor I need them: it is immediately obvious to > me. > > BTW, I'll say this for the last time: > > In Elisp, + is not the binary addition operator. It is the summation > operator (aka Σ) for finite sequences. > > In Elisp, * is not the binary multiplication operator. It is the product > operator (aka Π) for finite sequences. > > Once you internalize this, things will be clearer. I understand your statement above as following: - in Elisp, there is no particular practical use for (*) ➜ 1 - there is theoretical only, and representativ use, as (*) ➜ 1 talks about summation for finite sequences -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/