From: Jean Louis <bugs@gnu.support>
To: Tassilo Horn <tsdh@gnu.org>
Cc: emacs-tangents@gnu.org
Subject: Re: (*) -> 1
Date: Fri, 20 Jan 2023 15:46:04 +0300 [thread overview]
Message-ID: <Y8qNDKdApYyL/tuc@protected.localdomain> (raw)
In-Reply-To: <87edrplgee.fsf@gnu.org>
* Tassilo Horn <tsdh@gnu.org> [2023-01-20 12:12]:
> Jean Louis <bugs@gnu.support> writes:
>
> >> Gosh, Jean, of course nobody would literally write (*) but (apply #'*
> >> ...), and you'll find occurrences in emacs:
> >
> > That has been said that is not necessarily problem or reason.
>
> I don't understand that sentence.
>
> > Did you see reference to PicoLisp?
>
> Yes, and I think it's seriously wrong with
>
> : (+)
> -> NIL
>
> where its docs say
>
> 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:07 <jmarciano> may somebody experienced with PicoLisp tell me if
(*) returning NIL in PicoLisp is obstacle or
feature? It is because I am trying to find use of
the function in other Lisp where (*) ➜ 1,
however, apparently, the use for it does not
exist. I have found PicoLisp returning NIL on
empty (*)
15:08 <jmarciano> Was author of PicoLisp aware that other Lisp
return (*) ➜ 1 at time of making it?
15:08 <jmarciano> And what was decision of author, reasoning, why
not to include it?
15:08 <abu[m]> Hi jmarciano! Well, I'm the author.
15:08 <jmarciano> Which reasoning I favor, as I rather like NIL
returned, rather than finding out where did I
miss to place the numbers.
15:09 <jmarciano> Nice to meet you.
15:09 <abu[m]> It is a "feature" that NIL propagates through
arithmetics
15:09 <jmarciano> How does it help instead of providing identity
elements?
15:09 <abu[m]> (*) especially was not contemplated though, it is a
pretty useless call
15:10 <abu[m]> but (+ 3 NIL) -> NIL was desired
15:10 <jmarciano> and why?
15:11 <jmarciano> Were you aware at the time of authoring it, that
other Lisp was giving (*) ➜ 1
15:11 <abu[m]> It is very convenient. I think I have hundreds of
cases where I rely on getting NIL when not all
argumets are ready (yet)
15:11 <abu[m]> very common in valuen from GUI
15:11 <abu[m]> A was not aware
15:11 <abu[m]> and never cared about other Lisps
15:12 <jmarciano> (*) ➜ 1, (+) ➜ 0, (-) ➜ 0, that is in Emacs Lisp
15:12 <abu[m]> Note that PicoLisp is very different from most Lisps
anywad
15:12 <abu[m]> What is a call like (*) useful for?
As you see, author also asked naturally why is it useful.
> So why does it return NIL? And why do you apparently consider that
> useful? And can something be useful even though it is incorrect?
I find it right as with error raising or nil I can find what is
wrong. I would not like forgetting some arguments and getting (*) ➜ 1
when instead I had to write something like (* a b). Even this case is
rare I find error better, or NIL, as with NIL I can't to other
mathematical operations, I will get error:
(* nil 2) will not work, and that will help me put attention on
it. Similarly (* (*) 2) would raise error putting my attention that I
forgot some arguments, then I would correct and write (* (* a b) 2).
Something is maybe "correct" in somebody's opionion but have no
practical use. And question was not what somebody considers correct,
but what is the practical use of it.
There are X mathematical subjects that are not injected in Emacs Lisp
functions just to be discovered they exist for themselves only.
Functions should serve a purpose, not only representation purpose of
some mathematica subject.
Function `*' to me should serve purpose of multiplication, not
representation of set theory or identity elements, UNLESS those
identity elements are useful somewhere.
And I asked for case where it is useful.
There is so far none case found, apart from mathematical
representation for those people who like to talk about it.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
next prev parent reply other threads:[~2023-01-20 12:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Y8Y2JgamG+C2VxFw@protected.localdomain>
[not found] ` <87y1q1kvdm.fsf@web.de>
[not found] ` <Y8bM7K8T9uMHdSRw@protected.localdomain>
[not found] ` <87h6wpkrlq.fsf@web.de>
[not found] ` <Y8bjItPWgBLLdR9s@protected.localdomain>
[not found] ` <87zgahj7h3.fsf@web.de>
[not found] ` <Y8fly8k72s+iVJYF@protected.localdomain>
[not found] ` <878rhzvs1h.fsf@web.de>
[not found] ` <Y8kAkHzCnCS35D8v@protected.localdomain>
[not found] ` <87ilh28w9u.fsf@web.de>
2023-01-19 14:54 ` (*) -> 1 Jean Louis
[not found] ` <Y8lZmM1EQ+wShgt2@protected.localdomain>
[not found] ` <87r0vqa67k.fsf@gnu.org>
2023-01-20 7:05 ` Jean Louis
2023-01-20 8:52 ` Tassilo Horn
2023-01-20 12:46 ` Jean Louis [this message]
2023-01-20 13:02 ` Tassilo Horn
2023-01-20 16:06 ` Jean Louis
2023-01-21 8:19 ` Tassilo Horn
2023-01-22 4:30 ` Emanuel Berg
2023-01-22 6:55 ` Jean Louis
2023-01-22 10:56 ` Emanuel Berg
2023-01-23 3:40 ` [External] : " Drew Adams
2023-01-22 14:34 ` Akib Azmain Turja
2023-01-23 2:23 ` Emanuel Berg
2023-01-23 5:37 ` Jean Louis
2023-01-23 5:55 ` Jean Louis
2023-01-24 2:33 ` Emanuel Berg
[not found] ` <SJ0PR10MB5488B34F22BFC45644C9C647F3C49@SJ0PR10MB5488.namprd10.prod.outlook.com>
2023-01-20 7:33 ` [External] : " Jean Louis
[not found] <87bkmxkpzg.fsf@web.de>
[not found] ` <878ri1av5j.fsf@telefonica.net>
[not found] ` <87ilh4kgqo.fsf@web.de>
[not found] ` <87zgagakh5.fsf@telefonica.net>
[not found] ` <87cz7cka06.fsf@web.de>
[not found] ` <87v8l49t8w.fsf@telefonica.net>
[not found] ` <Y8evxjuR1YQWW10L@tuxteam.de>
[not found] ` <87h6wo9fjb.fsf@telefonica.net>
[not found] ` <87edrsufdd.fsf@web.de>
[not found] ` <878ri09bsh.fsf@telefonica.net>
2023-01-19 8:37 ` Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8qNDKdApYyL/tuc@protected.localdomain \
--to=bugs@gnu.support \
--cc=emacs-tangents@gnu.org \
--cc=tsdh@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).