From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.tangents Subject: Re: (*) -> 1 Date: Sat, 21 Jan 2023 09:19:22 +0100 Message-ID: <87y1pwqneb.fsf@gnu.org> References: <878rhzvs1h.fsf@web.de> <87ilh28w9u.fsf@web.de> <87r0vqa67k.fsf@gnu.org> <87edrplgee.fsf@gnu.org> <87a62dl55j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34383"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.16; emacs 30.0.50 Cc: emacs-tangents@gnu.org To: Jean Louis Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Sat Jan 21 09:53:55 2023 Return-path: Envelope-to: get-emacs-tangents@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 1pJ9dL-0008le-2K for get-emacs-tangents@m.gmane-mx.org; Sat, 21 Jan 2023 09:53:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJ9d4-0005ed-Pz; Sat, 21 Jan 2023 03:53:38 -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 1pJ9d3-0005eL-1B for emacs-tangents@gnu.org; Sat, 21 Jan 2023 03:53:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJ9d2-0006AH-ME; Sat, 21 Jan 2023 03:53:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=5xe4mzAtWGBeW0b6fuIDKQvn9l5lbiUMzOod8JrOoCE=; b=Kli9HUzV3049yj tSwIJ2nLf6kjuYW9qKS5qUZ76HNP7gV+8vSoEM8UepDuVN81cPIIulIsXJKR0PYAFlOYocmc6/ihz TlWsuAo7/edSBKZ5FFS8I9LaiqFUZNaDw5Q+nFW2OObaLPWknXRnWocEEAMpLwbU+dyvL9jugXAmg E756e7gW/iVctWbNbPInETB+bO9Yj9z3+QMNSSZrTRpSe9moHtNIF9xVhiCIPmw6Ps9Eaa5SdRp2P 0CnzXuY6+cN7gZbEtQyTAFmcF3JJN4L8bQFBu9TNNdHZUg7UqkMNIC672zeaq2NbwGz33h1bMSzhY U669872CNMtkv5BQs4uQ==; Original-Received: from auth1-smtp.messagingengine.com ([66.111.4.227]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pJ9d2-0004ia-CD; Sat, 21 Jan 2023 03:53:36 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id C127A27C0054; Sat, 21 Jan 2023 03:53:35 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 21 Jan 2023 03:53:35 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddufedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfhgfhffvvefuffgjkfggtgfgse htqhertddtreejnecuhfhrohhmpefvrghsshhilhhoucfjohhrnhcuoehtshguhhesghhn uhdrohhrgheqnecuggftrfgrthhtvghrnhepgfettdduiedvhfffhfefhfevhfeuvdehje ejfeelffehkeffuedthffgjeeihfegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhrnhdomhgvshhmthhprghuthhhphgvrhhsohhnrg hlihhthidqkeeijeefkeejkeegqdeifeehvdelkedqthhsughhpeepghhnuhdrohhrghes fhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Feedback-ID: ib2b94485:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 21 Jan 2023 03:53:34 -0500 (EST) In-reply-to: X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Original-Sender: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.tangents:974 Archived-At: Jean Louis writes: >> >> Yes, and I think it's seriously wrong with >> >>=20 >> >> : (+) >> >> -> NIL >> >>=20 >> >> where its docs say >> >>=20 >> >> Returns the sum of all num arguments. When one of the arguments >> >> evaluates to NIL, it is returned immediately. >> > >> > For some reason PicoLisp is quite different than other Lisp. I have >> > asked author about it. >> > >> > 15:09 It is a "feature" that NIL propagates through >> > arithmetics >>=20 >> Well, but with (*) and (+), there is no single NIL involved! And in >> Elisp (+ nil), where actually a nil is involved, you get an error. > > What we can learn from PicoLisp is that there was no use for (*) =E2=9E= =9C 1 > and that programs work, GUI applications and Android/Replicant work, > and there was no use of (*) =E2=9E=9C 1 so far. You are jumping to conclusions. If someone needed a mathematically sound product in PicoLisp, they might have defined it as (de product @ (if (not (args)) 1 (* (next) (apply 'product (rest))))) [Not sure if that's correct, I've just skimmed the docs.] >> > 15:09 How does it help instead of providing identity >> > elements? >> > 15:09 (*) especially was not contemplated though, it is a >> > pretty useless call >> > [...] >> > 15:12 What is a call like (*) useful for? >> > >> > As you see, author also asked naturally why is it useful. >>=20 >> So go and ask why he thinks (apply '+ ()) -> NIL is more useful than >> 0 given that the sum of the empty set of numbers _is_ 0. > > I will ask. I'm interested in the reply. I feel it might be just an oversight which is hard or impossible to fix now. > But docstring does not speak of empty sets. Yes, so the docstring is at least incomplete because it doesn't include the completely valid case where no args are given. > You introduce "sets" where there is not direct relation to it. 17 is an element of the set of integers, isn't it? > (+ &rest NUMBERS-OR-MARKERS) > > Return sum of any number of arguments, which are numbers or > markers. Of course I get confused. Why? At least when ignoring markers which happen to have an integer representation which is an implementation detail. > `apply' can be used with (apply '+ '(a b)) as why would you need in > apply for addition two arguments? You don't but you can use it if (a b) is not a literal list but a variable, i.e., use (+ a b) or (apply #'+ my-list-of-numbers). >> It's good to signal an error when the expression is wrong as does >> Elisp with >>=20 >> (+ nil) >> (* 1 2 nil) >> (apply #'+ (list 1 nil 19)) >> (+ 2 "i am not a number") > > That is exactly my point, what you see useful there, I see too. Good! :-) > Making it less error prone with useless default identity elements > hides the real event preceding the operation. Let's agree to disagree then. In my book, it is useful to have mathematically sound behavior by default. If you have a reason to handle some edge-cases differently in some application (which is totally possible!), then define your own function which does what you wish. Bye, Tassilo