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: [External] : Re: How to make M-x TAB not work on (interactive) declaration? Date: Wed, 18 Jan 2023 17:32:44 +0300 Message-ID: References: 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="2290"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Cc: "tomas@tuxteam.de" , "help-gnu-emacs@gnu.org" To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 18 20:19:33 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 1pIDy9-0000Ls-59 for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 20:19:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIDxT-0003Nc-0l; Wed, 18 Jan 2023 14:18:51 -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 1pIDxJ-0003Lm-Mx for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 14:18:41 -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 1pIDx9-00040j-P0 for help-gnu-emacs@gnu.org; Wed, 18 Jan 2023 14:18:40 -0500 Original-Received: from localhost ([::ffff:197.239.7.243]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103A0D.0000000063C845D0.000041A7; Wed, 18 Jan 2023 12:17:21 -0700 Mail-Followup-To: Drew Adams , "tomas@tuxteam.de" , "help-gnu-emacs@gnu.org" Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-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:142375 Archived-At: * Drew Adams [2023-01-18 01:28]: > Jean Louis: > > Imagine that functions such as + and * accept a > single _list_ argument, _instead of_ a variable > number (including zero) of arguments. > > Can you see that such a function is useful? No. (* 2) ➜ 2 I do not see how it is useful, except for some funny stuff. > Can you see that it's general - and that you can even pass it the > empty list or a singleton list? I can't pass list in this way (* nil) and I do not know how you wish to pass it. If you mean with `apply', PicoLisp (*) ➜ NIL, but can do `apply', so I do not think that is problem really, and that it was made to make Lisp implementation work, if you mean that. > OK, let's look into that... > > Such functions would cdr down the list argument > adding/multiplying the next number from the list > by the sum/product accumulated so far. Was it so maybe in some early Lisp? I don't know C language, do you see in this definition of function some CDR? DEFUN ("*", Ftimes, Stimes, 0, MANY, 0, doc: /* Return product of any number of arguments, which are numbers or markers. usage: (* &rest NUMBERS-OR-MARKERS) */) (ptrdiff_t nargs, Lisp_Object *args) { if (nargs == 0) return make_fixnum (1); Lisp_Object a = check_number_coerce_marker (args[0]); return nargs == 1 ? a : arith_driver (Amult, nargs, args, a); } > The functions would have to start with _some_ initial value for the > accumulated sum/product. Is it so in the C language function? I can't see. > It's far simpler and more general for them to > initialize at the top level: _before_ dealing > with the first arg. The obvious init-value > choice for + is zero, and the obvious choice > for * is one. That's all that's going on. > > Or, what initial values would you have such > functions start with, for their accumulating > sum/product? Clearly you'd want + to start > with 0 and * to start with 1, no? If dividion (/ 10 2) is initialized with 10, then (* A B) can be initialized by A. I expect error. So there was some notion in Lisp that arguments shall be imagined: (* 10) ➜ 10 imagines absent element 1 (* 1 10) ➜ 10 (+ 10) ➜ 10 imagines absent element 0 (+ 0 10) ➜ 10 (- 10) ➜ -10 imagines absent element 0 (- 0 10) ➜ -10 (/ 10) ➜ 0 imagines absent elemet (/ 0 10) ➜ 0 Then imaginagion goes on: (*) ➜ 1 (+) ➜ 0 (-) ➜ 0 Without practical use I can only tell it is capricious decision. Maybe we can tell it this way: If there is any Emacs Lisp program which does not use (*) or (* a) anywhere but which would raise error if we re-define function to require 2 arguments -- then there must be some use of it. Otherwise I get idea it was just pecular decision. > Now, what value would you have + return for a > singleton list - e.g., (42)? What value would > you have it return for the empty list, ()? I > think you'd want (+ '(42)) to return 42 and > (+ ()) to return 0, no? If so, why? (That's > the question others have been answering by > mentioning additive/multiplicative identities.) Just that (+ nil) does not really work. Example cannot be shown practically. It is for adding numbers, not for adding numbers in a list. I understand you are extrapolating hypothesis which works for you, but the test for hypothesis is there above, to show the Emacs Lisp small program which without using single argument and in absence of argument would break if those functions would yield error instead of identity element. Which Emacs Lisp program will break if we demand 2 elements for *, - and + ? By answering that question we can see where it is usable. PicoLisp is confusing there as it asks for arguments, does not give identity elements and `apply' works alright. > Now consider functions such as min and max. > > There's no minimum or maximum number, so they > clearly can't be called with _no_ args. But > they can be called with a _single_ arg, and, > like + and *, their definitions return that > number - it's _not compared_ with any other > number, so how can we say it's the smallest > or largest? It's the smallest/largest of the > numbers provided - no comparison is needed. (min 1 2) ➜ 1 (max 2 3) ➜ 3 Then if * and + and - are analogous, I wish to find program that breaks if those functions require 2 arguments. Or do you think it was just made because it has to be made that way, and that is authoritative opinion of mathematicians, but we have absolutely no use of it in Lisp? If (/) gives error then (apply '/ '()) gives error. When (*) ➜ 1 does not give error (apply '* '()) ➜ 1 also does not give error. So is it about errors? If it is about errors, why then we allow / to have error but * not to have error? For me is not logical this: (apply '* '()) ➜ 1 because I want error to tell me that I did not provide arguments for multiplication. > If you don't like Lisp's predefined +, *, etc. > it's simple enough to roll your own, and make > them _require at least 2_ arguments. E.g.: > > (defmacro my-plus (n1 n2 &rest ns) > "..." > `(+ ,n1 ,n2 ,@ns)) OK let us see that: (defun my-plus (n1 n2 &rest ns) "..." (eval `(+ ,n1 ,n2 ,@ns))) (my-plus 2 2) ➜ 4 (my-plus 3 4 5) ➜ 12 (apply 'my-plus (list 3 4 5)) ➜ 12 (my-plus 3) -- error OK so that can work with `apply' quite well, even if not in that form, one could make it probaly in different way. It is thus not for reason of `apply'. So, I tend to conclude that reason is peculiar decision of some authors who wanted to make it look more "mathematical" (just because) even though there is no practical use of it. And I still hope to find the true background of it. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/