How to make M-x TAB not work on (interactive) declaration?

How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

Reference:
(describe-function 'interactive)

If MODES is present, it should be a list of mode names (symbols) that
this command is applicable for.  The main effect of this is that
‘M-x TAB’ (by default) won’t list this command if the current buffer’s
mode doesn’t match the list.  That is, if either the major mode isn’t
derived from them, or (when it’s a minor mode) the mode isn’t in effect.

For this example here I can still see it in M-x TAB expansion in any
mode.

(defun my-function ()
  (interactive nil '(text-mode))
  (message "Hello"))


And I expect not to see it.

What am I doing wrong?


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: How to make M-x TAB not work on (interactive) declaration?

[Ruijie Yu via Users list for the GNU Emacs text editor]

Jean Louis <bugs@gnu.support> writes:

> Reference:
> (describe-function 'interactive)
>
> If MODES is present, it should be a list of mode names (symbols) that
> this command is applicable for.  The main effect of this is that
> ‘M-x TAB’ (by default) won’t list this command if the current buffer’s
> mode doesn’t match the list.  That is, if either the major mode isn’t
> derived from them, or (when it’s a minor mode) the mode isn’t in effect.
>
> For this example here I can still see it in M-x TAB expansion in any
> mode.
>
> (defun my-function ()
>   (interactive nil '(text-mode))
>   (message "Hello"))
>
>
> And I expect not to see it.
>
> What am I doing wrong?

Can confirm on both 29 and 28.  Although I think you missed the `&rest'
in the argument list, so you would only need to say

    (interactive nil #'text-mode)

In my testing, I tried to define:

    (defun foo () (interactive nil #'text-mode) 2)

Running M-x fo TAB while inside an `ielm' buffer completes the `foo'
command, which should not happen according to the quoted documentation.

On a slight tangent, I tried to use M-X (M-S-x,
`execute-extended-command-for-buffer'), and regardless of what major
modes I am in, I cannot find or call the `foo' command.

Best,


RY

Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Ruijie Yu <ruijie@netyu.xyz> [2023-01-08 00:28]:
> > (defun my-function ()
> >   (interactive nil '(text-mode))
> >   (message "Hello"))

Instead of above, I should do:

(defun my-function-1 ()
  (interactive nil 'text-mode 'fundamental-mode)
  (message "Hello"))

But I still see "my-function-1" when using TAB.

> Can confirm on both 29 and 28.  Although I think you missed the `&rest'
> in the argument list, so you would only need to say
> 
>     (interactive nil #'text-mode)
> 
> In my testing, I tried to define:
> 
>     (defun foo () (interactive nil #'text-mode) 2)
> 
> Running M-x fo TAB while inside an `ielm' buffer completes the `foo'
> command, which should not happen according to the quoted documentation.
> 
> On a slight tangent, I tried to use M-X (M-S-x,
> `execute-extended-command-for-buffer'), and regardless of what major
> modes I am in, I cannot find or call the `foo' command.

And I switched to text-mode and M-X does not show me the function.

This is inverse and awkward as to what is written in documentation.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: How to make M-x TAB not work on (interactive) declaration?

[Eli Zaretskii]

> Date: Sat, 07 Jan 2023 23:53:48 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> 
> Reference:
> (describe-function 'interactive)
> 
> If MODES is present, it should be a list of mode names (symbols) that
> this command is applicable for.  The main effect of this is that
> ‘M-x TAB’ (by default) won’t list this command if the current buffer’s
> mode doesn’t match the list.  That is, if either the major mode isn’t
> derived from them, or (when it’s a minor mode) the mode isn’t in effect.
> 
> For this example here I can still see it in M-x TAB expansion in any
> mode.
> 
> (defun my-function ()
>   (interactive nil '(text-mode))
>   (message "Hello"))
> 
> 
> And I expect not to see it.
> 
> What am I doing wrong?

The doc string is wrong: the default is to show all commands.  If you
want to see only those relevant to MODES, either use M-X (upper-case
X) or customize read-extended-command-predicate's value to be the
function command-completion-default-include-p.

Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

Eli Zaretskii wrote:

>> What am I doing wrong?
>
> The doc string is wrong

Jean, know that you are not actually supposed to _read_
the docstrings!

-- 
underground experts united
https://dataswamp.org/~incal

Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-08 21:12]:
> Eli Zaretskii wrote:
> 
> >> What am I doing wrong?
> >
> > The doc string is wrong
> 
> Jean, know that you are not actually supposed to _read_
> the docstrings!

☺️

Do you want to say I am chainik?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

algorithmic Lisp language (was: Re: How to make M-x TAB not work on (interactive) declaration?)

[Emanuel Berg]

Jean Louis wrote:

>>>> What am I doing wrong?
>>>
>>> The doc string is wrong
>> 
>> Jean, know that you are not actually supposed to _read_
>> the docstrings!
>
> ☺️
>
> Do you want to say I am chainik?

Elisp dlia chainikof - The fun and easy way!

I have often thought one should have a minimal Lisp language
instead of a maximalist one [we don't have to outlaw the
maximalist ones] so that the minimal one would be accessible
to anyone instantly, but then one would program not one
zillion modules so it would be impossible to know where to
start anyway, no, instead one would implement known algorithms
in that minimal language - indeed, sounds pretty fun and
easy, right? (E.g. Bubblesort [1] or whatever.)

Then one would have a superstructure language not of
programming code as we are used to it, but of a special
notation, actually a new code, but denoting those algorithms
and how they would link and combine ...

[1] https://en.wikipedia.org/wiki/Bubble_sort

-- 
underground experts united
https://dataswamp.org/~incal

Re: algorithmic Lisp language (was: Re: How to make M-x TAB not work on (interactive) declaration?)

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-09 19:28]:
> > ☺️
> >
> > Do you want to say I am chainik?
> 
> Elisp dlia chainikof - The fun and easy way!

From The Jargon File (version 4.4.7, 29 Dec 2003) [jargon]:

chainik
 /chi:'nik/

    [Russian, literally ?teapot?] Almost synonymous with muggle. Implies both
    ignorance and a certain amount of willingness to learn, but does not
    necessarily imply as little experience or short exposure time as newbie
    and is not as derogatory as luser. Both a novice user and someone using a
    system for a long time without any understanding of the internals can be
    referred to as chainiks. Very widespread term in Russian hackish, often
    used in an English context by Russian-speaking hackers esp. in Israel (e.g.
    ?Our new colleague is a complete chainik?). FidoNet discussion groups often
    had a ?chainik? subsection for newbies and, well, old chainiks (eg.
    su.asm.chainik, ru.linux.chainik, ru.html.chainik). Public projects often
    have a chainik mailing list to keep the chainiks off the developers' and
    experienced users' discussions. Today, the word is slowly slipping into
    mainstream Russian due to the Russian translation of the popular
    yellow-black covered ?foobar for dummies? series, which (correctly) uses ?
    chainik? for ?dummy?, but its frequent (though not excessive) use is still
    characteristic hacker-speak.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: algorithmic Lisp language (was: Re: How to make M-x TAB not work on (interactive) declaration?)

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-09 19:28]:
> I have often thought one should have a minimal
> Lisp language instead of a maximalist one [we
> don't have to outlaw the maximalist ones] so
> that the minimal one would be accessible to
> anyone instantly, but then one would program not
> one zillion modules so it would be impossible to
> know where to start anyway, no, instead one
> would implement known algorithms in that minimal
> language - indeed, sounds pretty fun and easy,
> right? (E.g. Bubblesort [1] or whatever.)

> Then one would have a superstructure language
> not of programming code as we are used to it,
> but of a special notation, actually a new code,
> but denoting those algorithms and how they would
> link and combine ...

Sounds to me as Prolog.

From The Collaborative International Dictionary of English v.0.48 [gcide]:

PROLOG \PRO"LOG\ (pr[=o]"l[o^]g), n. (Computers)
   A declarative higher-level programming language in which
   instructions are written not as explicit procedural
   data-manipulation commands, but as logical statements. The
   language has built-in resolution procedures for logical
   inference.
   [PJC]

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2023-01-08 09:07]:
> > And I expect not to see it.
> > 
> > What am I doing wrong?
> 
> The doc string is wrong: the default is to show all commands.  If you
> want to see only those relevant to MODES, either use M-X (upper-case
> X) or customize read-extended-command-predicate's value to be the
> function command-completion-default-include-p.

Now we know that there is some inconsistency, thanks for confirming
it.

For this function:

(defun my-function ()
  (interactive nil '(text-mode mail-mode))
  (message "Hello"))

major-mode ➜ mail-mode

My default was:
(setq read-extended-command-predicate nil)

- I can see 90 possible completions with M-X in mail-mode, WITHOUT `my-function'

- I can see 9819 possible completions with M-x in mail-mode, WITH `my-function'

when I turn it on:

(setq read-extended-command-predicate 'command-completion-default-include-p)

- I can see 90 possible completions with M-X in mail-mode, WITHOUT `my-function'

- I can see 8777 possible completions with M-x in mail-mode, WITHOUT `my-function'

Which means that my function cannot be found with recommended
settings in mail-mode, so there must be more inconsistencies.

I have filed the above as bug, it is best to continue discussion as
bug.

But in the bug there shall be wording "I can see 8777" just as in
here, there was mistake.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

Jean Louis wrote:

> I have filed the above as bug, it is best to continue
> discussion as bug.

Very good work ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: How to make M-x TAB not work on (interactive) declaration?

[Eli Zaretskii]

> Date: Sun, 8 Jan 2023 09:21:32 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2023-01-08 09:07]:
> > > And I expect not to see it.
> > > 
> > > What am I doing wrong?
> > 
> > The doc string is wrong: the default is to show all commands.  If you
> > want to see only those relevant to MODES, either use M-X (upper-case
> > X) or customize read-extended-command-predicate's value to be the
> > function command-completion-default-include-p.
> 
> Now we know that there is some inconsistency, thanks for confirming
> it.
> 
> For this function:
> 
> (defun my-function ()
>   (interactive nil '(text-mode mail-mode))
>   (message "Hello"))
> 
> major-mode ➜ mail-mode
> 
> My default was:
> (setq read-extended-command-predicate nil)
> 
> - I can see 90 possible completions with M-X in mail-mode, WITHOUT `my-function'
> 
> - I can see 9819 possible completions with M-x in mail-mode, WITH `my-function'
> 
> when I turn it on:
> 
> (setq read-extended-command-predicate 'command-completion-default-include-p)
> 
> - I can see 90 possible completions with M-X in mail-mode, WITHOUT `my-function'
> 
> - I can see 8777 possible completions with M-x in mail-mode, WITHOUT `my-function'
> 
> Which means that my function cannot be found with recommended
> settings in mail-mode, so there must be more inconsistencies.
> 
> I have filed the above as bug, it is best to continue discussion as
> bug.
> 
> But in the bug there shall be wording "I can see 8777" just as in
> here, there was mistake.

You reported a bug, so let's continue discussing this there.

In general, I believe your expectations were wrong.

Re: How to make M-x TAB not work on (interactive) declaration?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> Reference:
> (describe-function 'interactive)
>
> If MODES is present, it should be a list of mode names (symbols) that
> this command is applicable for.  The main effect of this is that ‘M-x
> TAB’ (by default) won’t list this command if the current buffer’s mode
> doesn’t match the list.  That is, if either the major mode isn’t
> derived from them, or (when it’s a minor mode) the mode isn’t in
> effect.

MODES is a &rest argument and the mode symbols shouldn't be quoted, so
you use it like so:

(defun my-function ()
  (interactive nil text-mode some-other-mode)
  (message "Hello"))

> For this example here I can still see it in M-x TAB expansion in any
> mode.

You also have to set

(setq read-extended-command-predicate
      #'command-completion-default-include-p)

I've added that to my init.el when the feature was built, see the info
docs at (info "(emacs) M-x"):

--8<---------------cut here---------------start------------->8---
   In addition, ‘M-x’ completion can exclude commands that are not
relevant to, and generally cannot work with, the current buffer’s major
mode (*note Major Modes::) and minor modes (*note Minor Modes::).  By
default, no commands are excluded, but you can customize the option
‘read-extended-command-predicate’ to exclude those irrelevant commands
from completion results.
--8<---------------cut here---------------end--------------->8---

You are right that this is feature is probably not documented good
enough.  It seems `command-completion-default-include-p' isn't
documented at all (but customize knows about it) and the `interactive'
docstring is missing references to that and
`read-extended-command-predicate', too.  I'd suggest to write a bug
report.

Bye,
Tassilo

Re: How to make M-x TAB not work on (interactive) declaration?

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: help-gnu-emacs@gnu.org
> Date: Sun, 08 Jan 2023 09:34:28 +0100
> 
> You are right that this is feature is probably not documented good
> enough.  It seems `command-completion-default-include-p' isn't
> documented at all (but customize knows about it) and the `interactive'
> docstring is missing references to that and
> `read-extended-command-predicate', too.  I'd suggest to write a bug
> report.

These deficiencies should be already fixed on the emacs-29 branch.

Re: How to make M-x TAB not work on (interactive) declaration?

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Sun, 08 Jan 2023 09:34:28 +0100
>> 
>> You are right that this is feature is probably not documented good
>> enough.  It seems `command-completion-default-include-p' isn't
>> documented at all (but customize knows about it) and the `interactive'
>> docstring is missing references to that and
>> `read-extended-command-predicate', too.  I'd suggest to write a bug
>> report.
>
> These deficiencies should be already fixed on the emacs-29 branch.

Yes, LGTM.

Thanks,
Tassilo

Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2023-01-08 11:46]:
> Jean Louis <bugs@gnu.support> writes:
> 
> Hi Jean,
> 
> > Reference:
> > (describe-function 'interactive)
> >
> > If MODES is present, it should be a list of mode names (symbols) that
> > this command is applicable for.  The main effect of this is that ‘M-x
> > TAB’ (by default) won’t list this command if the current buffer’s mode
> > doesn’t match the list.  That is, if either the major mode isn’t
> > derived from them, or (when it’s a minor mode) the mode isn’t in
> > effect.
> 
> MODES is a &rest argument and the mode symbols shouldn't be quoted, so
> you use it like so:
> 
> (defun my-function ()
>   (interactive nil text-mode some-other-mode)
>   (message "Hello"))

Then is not good to say "it should be a list of mode names". Of course
after &rest the argument becomes list, but is not same thing.

Thanks, this way I find that function does not appear in other modes.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> Then is not good to say "it should be a list of
> mode names". Of course after &rest the argument
> becomes list, but is not same thing.

I' sure you know this, but maybe it's worth
repeating:

Yes and no.  Yes, a parameter specified in a
function definition is not the same thing as an
actual argument in a given application of the
function.

But no, depending on how "it" is read, it _can_
be said to be the same thing.

MODES is a formal parameter in the function
definition, but MODES is also the name of a
local variable in the function, a variable
that's bound, when the function is called, to
a list of actual arguments.  In a function call,
MODES _is_ the list of argument values; that is,
the value of variable MODES is that list.

(defun foo (a &rest b) (message "A: %S, B: %S" a b))
(foo 1 2 3 4)
==> "A: 1, B: (2 3 4)"

This is the definition of an &rest parameter.
`&rest MODES' is a formal parameter spec
(part of a "lambda list", which is part of a
function definition), which corresponds to a
list (possibly empty) of actual arguments.
Same thing in a lambda expression (definition
of an anonymous function).

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node64.html

"the lambda-list ... specifies names for the
 parameters of the function. When the function
 denoted by the lambda-expression is applied to
 arguments, the arguments are matched with the
 parameters specified by the lambda-list."

What is this "matching" for &rest?

"remaining arguments are made into a list for
 the &rest parameter"

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

Drew Adams wrote:

>> Then is not good to say "it should be a list of mode
>> names". Of course after &rest the argument becomes list,
>> but is not same thing.
>
> I'm sure you know this, but maybe it's worth repeating:
>
> Yes and no. Yes, a parameter specified in a function
> definition is not the same thing as an actual argument in
> a given application of the function. [...]

Just don't mention list, say it can be
any number of whatever ...

(+) ; 0

(*) ; 1

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-09 19:28]:
> (+) ➜ 0

Why? It is wrong.

> (*) ➜ 1

Why? It is wrong.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

Jean Louis wrote:

>> (+) ; 0
>
> Why? It is wrong.
>
>> (*) ; 1
>
> Why? It is wrong.

It makes sense in the way that 0 and 1 are the identity
elements for addition and multiplication, respectively.

-- 
underground experts united
https://dataswamp.org/~incal

(*)->1

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-13 03:23]:
> Jean Louis wrote:
> 
> >> (+) ; 0
> >
> > Why? It is wrong.
> >
> >> (*) ; 1
> >
> > Why? It is wrong.
> 
> It makes sense in the way that 0 and 1 are the identity
> elements for addition and multiplication, respectively.

I can think of it this way:nn

+ is function and it follows by nothing which is in this case
represented as zero. Nothing is zero, so result is zero. But nothing
is not zero that I know, mathematically. Zero at least has some value,
while nothing has no value.

See here:

(list) ➜ nil
(list 0) ➜ (0)

Thus (+) ➜ 0 without value result should not be zero. If no values
where given to addition, no addition has taken place. Value of zero
should not get out of nothing.

Multiplication is repeated addition.

Repeated addition of zero can't be 1.

(* 2 3) is equal (+ 3 3) ➜ 6
(* 4 3) is equal (+ 3 3 3 3) ➜ 12

How can then (*) ➜ 1 be equal to (+) ➜ 0 no matter how many times you
repeat it?

Thus this is wrong:

(+ (+) (+) (+) (+) (+) (+) (+) (+)) ➜ 0

One thing we learn here, we can finally express mathematical notation
very clearly:

for example that 2 + 2 = 4 is expressed as following from now on:

(+(+(*)(*))(+(*)(*))) ➜ 4

We can also easily teach children multiplication table every
Christmas:

(*(+(*))(+(*)(*))) ➜ 2
(*(+(*))(+(*)(*)(*))) ➜ 3
(*(+(*))(+(*)(*)(*)(*))) ➜ 4
(*(+(*))(+(*)(*)(*)(*)(*))) ➜ 5
(*(+(*))(+(*)(*)(*)(*)(*)(*))) ➜ 6
(*(+(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 7
(*(+(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 8
(*(+(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 9
(*(+(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 10
(*(+(*)(*))(+(*))) ➜ 2
(*(+(*)(*))(+(*)(*))) ➜ 4
(*(+(*)(*))(+(*)(*)(*))) ➜ 6
(*(+(*)(*))(+(*)(*)(*)(*))) ➜ 8
(*(+(*)(*))(+(*)(*)(*)(*)(*))) ➜ 10
(*(+(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 12
(*(+(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 14
(*(+(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 16
(*(+(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 18
(*(+(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 20
(*(+(*)(*)(*))(+(*))) ➜ 3
(*(+(*)(*)(*))(+(*)(*))) ➜ 6
(*(+(*)(*)(*))(+(*)(*)(*))) ➜ 9
(*(+(*)(*)(*))(+(*)(*)(*)(*))) ➜ 12
(*(+(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 15
(*(+(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 18
(*(+(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 21
(*(+(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 24
(*(+(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 27
(*(+(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 30
(*(+(*)(*)(*)(*))(+(*))) ➜ 4
(*(+(*)(*)(*)(*))(+(*)(*))) ➜ 8
(*(+(*)(*)(*)(*))(+(*)(*)(*))) ➜ 12
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 16
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 20
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 24
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 28
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 32
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 36
(*(+(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 40
(*(+(*)(*)(*)(*)(*))(+(*))) ➜ 5
(*(+(*)(*)(*)(*)(*))(+(*)(*))) ➜ 10
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*))) ➜ 15
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 20
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 25
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 30
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 35
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 40
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 45
(*(+(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 50
(*(+(*)(*)(*)(*)(*)(*))(+(*))) ➜ 6
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*))) ➜ 12
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*))) ➜ 18
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 24
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 30
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 36
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 42
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 48
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 54
(*(+(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 60
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*))) ➜ 7
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*))) ➜ 14
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*))) ➜ 21
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 28
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 35
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 42
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 49
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 56
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 63
(*(+(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 70
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*))) ➜ 8
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*))) ➜ 16
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*))) ➜ 24
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 32
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 40
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 48
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 56
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 64
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 72
(*(+(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 80
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*))) ➜ 9
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*))) ➜ 18
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*))) ➜ 27
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 36
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 45
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 54
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 63
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 72
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 81
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 90
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*))) ➜ 10
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*))) ➜ 20
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*))) ➜ 30
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*))) ➜ 40
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*))) ➜ 50
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*))) ➜ 60
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*))) ➜ 70
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 80
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 90
(*(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ 100

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*)->1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Thus (+) ➜ 0 without value result should not be zero. If no values
> where given to addition, no addition has taken place. Value of zero
> should not get out of nothing.

Mathematically it is neither right nor wrong.  It is a convention to
assign 0 to an empty sum.  This is for convenience, and it doesn't lead
to contradictions.

It is convenient because if you decompose a sum into partial sums,
equations remain correct for the corner case of empty partial sums: then
the contribution of an empty partial sum to the whole sum is 0.
Likewise for products and other operations.  This convention is used in
whole mathematics because it elegantly avoids case distinctions.

It's also a useful convention in programming.  For example, the initial
value of an accumulator of a sum calculation is 0.

If you sum up partial sums it would be nonsense to assign a special
value for empty partial sums that behaves like 0 but means

  0_{from zero summands}.

We also don't have

  7_{from 3 summands}

we just have 7.  The number of summands doesn't matter if you are
interested in a sum, even when the number of summands is zero.  Note
that nobody will ever use the expression (+) directly to find 0 to try
to learn something from it.  But the case may appear in calculations
like e.g. (apply #'+ args) and such where an empty arg list might appear.

Some other perspective: when you play a video game and got no rewarded
actions before game over, your score is typically 0.  You could also get
"void game" or no entry in the high score list.  As I said, it's a
mathematical convention, you can't derive something wrong from it, it's
just convenient.  We could make (+) error or emit something new but that
would just make Elisp worse.


Michael.

Re: (*)->1

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Jean Louis <bugs@gnu.support> writes:
>
> > Thus (+) ➜ 0 without value result should not be zero. If no values
> > where given to addition, no addition has taken place. Value of zero
> > should not get out of nothing.
>
> Mathematically it is neither right nor wrong.  It is a convention to
> assign 0 to an empty sum.  This is for convenience, and it doesn't lead
> to contradictions.

Some more comments:

1. The mathematical background is the associative property in monoids:

  https://en.wikipedia.org/wiki/Monoid

2.  You surely never complained about a^0 = 1 although "it's an empty
product".  You surely used that often because it's convenient.

3.  Similar things in Lisp are

(append) ==> ()
(concat) ==> ""
(or) ==> nil
(and) ==> t

The result is always the neutral element of the associative operation.

Michael.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Rudolf Adamkovič]

Jean Louis <bugs@gnu.support> writes:

>> (+) ➜ 0
>
> Why? It is wrong.

In Lisp, the `+' operator returns the sum of the additive identity with all of
its arguments.  The additive identity equals zero and you provided zero
arguments.  Hence, you get the additive identity.

>> (*) ➜ 1
>
> Why? It is wrong.

In Lisp, the `*' operator returns the product of the multiplicative identity and
all of its arguments.  The multiplicative identity equals one and you provided
zero arguments.  Hence, you get the multiplicative identity.

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."
-- Albert Einstein, 1879-1955

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Rudolf Adamkovič <salutis@me.com> [2023-01-15 23:19]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> (+) ➜ 0
> >
> > Why? It is wrong.
> 
> In Lisp, the `+' operator returns the sum of the additive identity with all of
> its arguments.  The additive identity equals zero and you provided zero
> arguments.  Hence, you get the additive identity.

It is interesting and I understand that it does, not that I agree that
it is correct. It is computer specific, not mathematics.

Nothing is not zero mathematically, so if I don't add any arguments,
there shall be no result that it is zero.

Difference Between Zero and Nothing | Compare the Difference Between Similar Terms:
https://www.differencebetween.com/difference-between-zero-and-vs-nothing/

What’s the difference between Zero and Nothing?

• ‘Zero’ is a number while ‘nothing’ is a concept.

• ‘Zero’ has numerical position value, while ‘nothing’ is not.

• ‘Zero’ has its own properties in arithmetic, while nothing has any
  such properties.

When we see function `+' 

Return sum of any number of arguments, which are numbers or markers.

Thus sum of any number of no arguments cannot be zero, because there
were no arguments.

> >> (*) ➜ 1
> >
> > Why? It is wrong.
> 
> In Lisp, the `*' operator returns the product of the multiplicative identity and
> all of its arguments.  The multiplicative identity equals one and you provided
> zero arguments.  Hence, you get the multiplicative identity.

Description says:

(* &rest NUMBERS-OR-MARKERS)

Return product of any number of arguments, which are numbers or
markers.

Product of no arguments cannot be possibly zero, so the function is
mathematically and by description incorrect.

I do understand that there is some LISP mystery why is it so.

If nothing would be equal to zero then following would be equal:

(* 0 0 ) ➜ 0
(*) ➜ 1

but they are not.



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> Return sum of any number of arguments, which are numbers or markers.
> 
> Thus sum of any number of no arguments cannot be zero,
> because there were no arguments.

Not to belabor this... but perhaps you're missing
understanding _zero as a number_, in "number of
arguments".  More precisely: zero or more args.

"Sum" can be defined in various ways, and yes, if
it's defined to accept _any number of args_ then
it's kosher, as one possibility, for "any number"
to include the fine, upstanding number that is zero.

> Description says:
> (* &rest NUMBERS-OR-MARKERS)
> Return product of any number of arguments, which are
> numbers or markers.
> 
> Product of no arguments cannot be possibly zero, so

Yes, it can.  And typically it is.  See sum, above.

Zero was apparently first considered a full-fledged
number in the 7th century, in India.  Europe didn't
catch on till the 12th century.  Before that, at
most it was a bookkeeping _placeholder_ for an
absence/nothing.

> I do understand that there is some LISP mystery
> why is it so.

This has nothing per se to do with Lisp.  And there's
really no mystery.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

Drew Adams wrote:

>> I do understand that there is some LISP mystery why is
>> it so.
>
> This has nothing per se to do with Lisp. And there's really
> no mystery.

It's the identity element:

  https://en.wikipedia.org/wiki/Identity_element

It makes sense in math and also in Lisp at least when we are
implementing a math operator.

This way it will make sense when we say "sum these elements
and add that sum to some other sum". If "these elements"
sometimes are no elements at all, adding 0 to the larger sum
is what you want to do.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-01-16 01:33]:
> > I do understand that there is some LISP mystery
> > why is it so.
> 
> This has nothing per se to do with Lisp.  And there's
> really no mystery.

So is nothing to do with Lisp but is in Lisp, and is no source of
information why is not so, but is not mystery. Then where is the
reference why is it so in Lisp?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> > > I do understand that there is some LISP mystery
> > > why is it so.
> >
> > This has nothing per se to do with Lisp.  And there's
> > really no mystery.
> 
> So is nothing to do with Lisp but is in Lisp, and is no source of
> information why is not so, but is not mystery. Then where is the
> reference why is it so in Lisp?

"This" in "This has nothing per se..." refers to
"perhaps [what] you're missing [is] understanding
_zero as a number_, in 'number of arguments'" (see
my post).

IOW, that "this" refers to what I explained about
zero, zero arguments, and "any number of arguments",
which is what I thought (and think) your basic
confusion was (and is) about.

If you understood what I explained, then I thought
you'd likely understand Lisp's following the typical
math convention here.

Others have explained the use of zero as an identity
in addition etc.

As for Lisp, beyond the simplicity, familiarity, and
elegance of following the typical math convention,
there's a (resulting) practical reason:

The use of `apply', pointed out by Anders, speaks
directly to "any number of arguments".  It applies
a function (e.g. `+') to "any number of arguments",
which are passed as a list.

A list can be empty - zero elements.  Letting `+'
act on zero elements (and on one element, BTW)
makes sense not only from a math point of view but
even just from a practical Lisp point of view - as
shown by not having to fiddle with any special cases
when using `+': you can just use `apply', regardless
of how many args there are to `+'.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-01-16 20:07]:
> > > > I do understand that there is some LISP mystery
> > > > why is it so.
> > >
> > > This has nothing per se to do with Lisp.  And there's
> > > really no mystery.
> > 
> > So is nothing to do with Lisp but is in Lisp, and is no source of
> > information why is not so, but is not mystery. Then where is the
> > reference why is it so in Lisp?
> 
> "This" in "This has nothing per se..." refers to
> "perhaps [what] you're missing [is] understanding
> _zero as a number_, in 'number of arguments'" (see
> my post).

I understand better.

Nevertheless description for those functions is not clearly written. 

> If you understood what I explained, then I thought
> you'd likely understand Lisp's following the typical
> math convention here.

Sorry, but I still did not understand why. 

It is like asking why is that flower in your pocket on your suit, and
you tell me how that flower is red, and it was always red flower of
that type.

But why is it on suit? 

> Others have explained the use of zero as an identity
> in addition etc.

Yes, I don't understand why is it in Lisp.

> The use of `apply', pointed out by Anders, speaks
> directly to "any number of arguments".  It applies
> a function (e.g. `+') to "any number of arguments",
> which are passed as a list.

Any number means also no argument? To me that is not clear. 

Any number of arguments is to me that it must be at least one
argument, not no argument.

I have got picture of justifications, but cannot see relation.

Example:
--------

* is a built-in function in ‘C source code’.

(* &rest NUMBERS-OR-MARKERS)

Return product of any number of arguments, which are numbers or markers.

But without having arguments, the product is one, which contradicts
multiplication how I know it.

(*) ➜ 1

The Group Theory and identity is there as definitions which I could
read, but I do not see relation between them and that function.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> > The use of `apply', pointed out by Anders, speaks
> > directly to "any number of arguments".  It applies
> > a function (e.g. `+') to "any number of arguments",
> > which are passed as a list.
> 
> Any number means also no argument? To me that is not clear.

That's why I pointed out that _zero is a number_.
A zero number of args means zero args, which
means no args.

> Any number of arguments is to me that it must be at least one
> argument, not no argument.

Zero is a number.  I have zero Ferraris. :-(

> * is a built-in function in ‘C source code’.
> (* &rest NUMBERS-OR-MARKERS)
> Return product of any number of arguments, which are numbers or markers.
> 
> But without having arguments, the product is one,
> which contradicts multiplication how I know it.

Yes, it's taking a shortcut, supposing that you
think of a "product" of one arg and a "product"
of zero args: (* N) -> N, (*) -> 0

But it's fairly common, for programmers at least,
to consider a "product" function as accepting any
number of arguments (or accepting a single list
of any number of elements).

Different definitions of a "product" function
are possible.  One that accepts zero or more
numbers as args (or a list of such as arg) is
handy - general, adaptable.

> (*) ➜ 1
> The Group Theory and identity is there as definitions which I could
> read, but I do not see relation between them and that function.

Imagine that you wanted to define a "product"
function that works with any number of args.
What would _you_ define as its behavior
(return value) for the zero-args case?  And
what would you use for the single-arg case?

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

On Tue, Jan 17, 2023 at 02:20:45AM +0000, Drew Adams wrote:
> > > The use of `apply', pointed out by Anders, speaks
> > > directly to "any number of arguments".  It applies
> > > a function (e.g. `+') to "any number of arguments",
> > > which are passed as a list.
> > 
> > Any number means also no argument? To me that is not clear.
> 
> That's why I pointed out that _zero is a number_.

Those are big words :-)

Minus one is also a number, but we'd be hard pressed to come
up with a function taking minus one arguments. Three-quarters,
the square root of two and pi are numbers. Arguably, "the"
Chaitin constant [1] (actually there are many of them)is also
a number.

I think the manual wants to say "natural number" and just
says "number", but that's OK, because it is directed at humans,
and we humans are usually better at disambiguating given a
context than at staying awake in front of long and boring texts.

Arguably, "zero or more" might be clearer here, but I don't
know (after all, the square root of two is bigger than zero,
too).

Now mathematicians don't agree on whether zero is a natural
number. The faculty I studied in started counting from zero,
but I've seen faculties which count from one. I once asked
a friend of mine teaching at one uni, and he told me faculties
having a strong mathematical logic department tended to start
with zero.

So zero may be a number or not, at least if you read "number"
as "natural number", and you ask a mathematician :)

Cheers

[1] There are uncountably many horrible monsters in the
    real numbers:
    https://en.wikipedia.org/wiki/Chaitin%27s_constant

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> > > Any number means also no argument? To me that is not clear.
> >
> > That's why I pointed out that _zero is a number_.
> 
> Those are big words :-)
> 
> Minus one is also a number, but we'd be hard pressed to come
> up with a function taking minus one arguments. Three-quarters,
> the square root of two and pi are numbers. Arguably, "the"
> Chaitin constant [1] (actually there are many of them)is also
> a number.
> 
> I think the manual wants to say "natural number" and just
> says "number", but that's OK, because it is directed at humans,
> and we humans are usually better at disambiguating given a
> context than at staying awake in front of long and boring texts.
> 
> Arguably, "zero or more" might be clearer here, but I don't
> know (after all, the square root of two is bigger than zero,
> too).

1. I said "More precisely: zero or more" in my
second reply to this thread:

  Not to belabor this... but perhaps you're missing
  understanding _zero as a number_, in "number of
  arguments".  More precisely: zero or more args.

2. There's no need to say anything more than
"any number of arguments" - the number of args
has to be zero or more, because we allow nullary
functions.

3. If someone has a hard time with functions of
variable arity, then just pretend you have this
equivalent: replace each Lisp function that
accepts a variable number of args with a function
that accepts a _list arg_ (whose elements are
what would be the variable number of args) in
their place.

Most functional, logic, etc. languages just use
a list arg - same difference.  There's nothing
magic about variable-arity functions - they're
really just functions that accept a list arg.

________________________
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?
Can you see that it's general - and that you
can even pass it the empty list or a singleton
list?

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.

The functions would have to start with _some_
initial value for the accumulated sum/product.

If they use simple recursion, applying the same
operation at each level (add/multiply next number
by accumulated sum/product), they need to start
by initializing the sum/product.

For them to seemingly start with the first number
in the list they'd need to initialize instead
within the general operation performed at each
level, which would require extra fiddling, to
(1) test whether it's the first time through
and if so then (2) initialize.

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?

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.)

Now, since Lisp allows variable-arity functions,
there's no reason to insist that an _explicit
list_ be passed, instead of just the elements
(numbers, here) that would be in that list.
That's the shortcut that Lisp takes: don't
bother to wrap the numbers in a list.

(Creating lists is costly: consing, and then
later garbage-collecting all those conses.
Using an explicit list gains us nothing.)

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.

And as for doc, note that the doc tells us
that there _must be at least one_ arg.  Well,
it doesn't tell you this in so many words (it
could; perhaps it should).  But the function
signature is part of its doc, and `C-h f max'
tells us:
___
max is a built-in function in ‘C source code’.

(max NUMBER-OR-MARKER &rest NUMBERS-OR-MARKERS)

Return largest of all the arguments (which must be numbers or markers).
The value is always a number; markers are converted to numbers.
___

"NUMBER-OR-MARKER &rest NUMBERS-OR-MARKERS"
tells you the function requires an argument,
and it accepts more than one arg.  If it
didn't require at least one arg then the
signature would be "&rest NUMBERS-OR-MARKERS ".
___

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))

And if you prefer to handle the identity
element explicitly, here's how to define a
`plus' function that does what + does, using
a more general, higher-order function, called
`reduce', aka `foldr':

(defun foldr (f init xs)
  (if (null xs)
      init
    (funcall f (car xs) (foldr f init (cdr xs)))))

(defun plus (&rest ns)
  (foldr #'my-plus 0 ns))

That is, Elisp's + (named `plus' here), could
be defined based on your `my-plus', using
`foldr', passing it 0 (additive identity) as
the initial element, argument INIT.

`plus' is just (1) your `my-plus', which
_requires two numbers_, (2) _folded_ into an
_explicit list_ of numbers - a list that
_can_ be empty or a singleton.

Elisp's + acts the same as that `plus', but
it's coded in C, and it creates no useless
intermediate list (to be garbage-collected).
________________________

Back to Tomas's mail...

> Now mathematicians don't agree on whether 
> zero is a natural number. 

That's just saying that they define "natural
number" differently.

> The faculty I studied in started counting from zero,
> but I've seen faculties which count from one. I once asked
> a friend of mine teaching at one uni, and he told me faculties
> having a strong mathematical logic department tended to start
> with zero.

This is a red herring here.  "Natural", "whole",
"countable"/"counting" numbers are just names.
Different definitions are sometimes given to the
names, yes.

When talking about the number of args a Lisp
function accepts, or the number of elements a list
can have, the counting is clearly zero-based: a
function can be nullary, and a list can be empty:
().  (Likewise, a string or a vector.)

> So zero may be a number or not, at least if you read "number"
> as "natural number", and you ask a mathematician :)

And if you read "number" as "triangular number"
then it's not.  This is really irrelevant here.
Clearly, if you read "number" as some set that
_excludes zero_, then zero doesn't belong to it.

Lisp functions can be nullary: take no arguments.
How many arguments?  Zero.  What's the _number_
of arguments a nullary function takes?  Zero.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Tue, Jan 17, 2023 at 10:20:47PM +0000, Drew Adams wrote:

[...]

> > Arguably, "zero or more" might be clearer here [...]

[...]

> 1. I said "More precisely: zero or more" in my
> second reply to this thread:

I was mulling over the manual's text, not over yours.

>   Not to belabor this... but perhaps you're missing
>   understanding _zero as a number_, in "number of
>   arguments".  More precisely: zero or more args.

I don't know who "you" is in this context: if you
meant "me" -- I do consider zero as a number, even
as a natural number (many influences conspirated
towards that). My point rather is:

 - "number" is pretty vague, and in this context
   often used sloppily [1] as "natural number",
   sometimes also for "whole number". There are
   many other "numbers"

 - not everyone considers zero as a natural number
   (even mathematicians "disagree" on that: it
   seems to vary from faculty to faculty)

 - you need some amount of sloppiness to make a
   documentation even viable.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

tomas@tuxteam.de wrote:

>> Not to belabor this... but perhaps you're missing
>> understanding _zero as a number_, in "number of arguments".
>> More precisely: zero or more args.
>
> I don't know who "you" is in this context: if you meant "me"
> -- I do consider zero as a number, even as a natural number
> (many influences conspirated towards that).

0 is not natural according to this source:

  https://dataswamp.org/~incal/data/numbers.txt

But (+) evals to zero because it's practical ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Wed, Jan 18, 2023 at 06:26:58AM +0100, Emanuel Berg wrote:
> tomas@tuxteam.de wrote:
> 
> >> Not to belabor this... but perhaps you're missing
> >> understanding _zero as a number_, in "number of arguments".
> >> More precisely: zero or more args.
> >
> > I don't know who "you" is in this context: if you meant "me"
> > -- I do consider zero as a number, even as a natural number
> > (many influences conspirated towards that).
> 
> 0 is not natural according to this source:
> 
>   https://dataswamp.org/~incal/data/numbers.txt

That source is wrong half of the time.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

tomas wrote:

>> 0 is not natural according to this source:
>> 
>>   https://dataswamp.org/~incal/data/numbers.txt
>
> That source is wrong half of the time.

The sources for the source are:

  https://davenport.libguides.com/math-skills-overview/basic-operations/sets
  https://www.geeksforgeeks.org/find-the-first-n-pure-numbers/

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On Thu, Jan 19, 2023 at 12:51:04PM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> >> 0 is not natural according to this source:
> >> 
> >>   https://dataswamp.org/~incal/data/numbers.txt
> >
> > That source is wrong half of the time.
> 
> The sources for the source are:
> 
>   https://davenport.libguides.com/math-skills-overview/basic-operations/sets
>   https://www.geeksforgeeks.org/find-the-first-n-pure-numbers/

Extend your sources. They aren't wrong, but they aren't right either.

I recommend at least skimming this discussion, which gives an idea
on how diverse the whole thing is:

  https://math.stackexchange.com/questions/283/is-0-a-natural-number

The most interesting answers, which parody what has been happening
here are those which say "it's this (or that) way because I learnt
it in school, dammit". 

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Robert Pluim]

>>>>> On Sat, 21 Jan 2023 15:05:09 +0100, <tomas@tuxteam.de> said:
    nil> The most interesting answers, which parody what has been happening
    nil> here are those which say "it's this (or that) way because I learnt
    nil> it in school, dammit". 

I went to a secondary school where the answer changed depending on
which teacher you talked to (they came from different countries :-))

Robert
-- 

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Michael Heerdegen]

<tomas@tuxteam.de> writes:

> Extend your sources. They aren't wrong, but they aren't right either.

BTW, treating 0 as a natural number or not reflects the difference in
these two things: you start counting objects with 1 (the first, the
second, ...).  OTOH counts of finite sets include 0 as the count of the
empty set - there can be 0 objects of a certain property.

For both things you use the same set of numbers apart from 0.  It's
of no value to argue which procedure should be the defining one for the
natural numbers.

Michael.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Mon, Jan 23, 2023 at 05:44:06PM +0100, Michael Heerdegen wrote:
> <tomas@tuxteam.de> writes:
> 
> > Extend your sources. They aren't wrong, but they aren't right either.
> 
> BTW, treating 0 as a natural number or not reflects the difference in
> these two things: you start counting objects with 1 (the first, the
> second, ...).  OTOH counts of finite sets include 0 as the count of the
> empty set - there can be 0 objects of a certain property.
> 
> For both things you use the same set of numbers apart from 0.  It's
> of no value to argue which procedure should be the defining one for the
> natural numbers.

Absolutely agree. For me, it's more interesting as a "sociology of
mathematicians" issue. The most satisfying observation I've heard,
as I already said, is that mathematical logic and set theory tends
to zero-counting (that would somewhat explain computer science's
affinity to that).

But as I said, in my experience (Germany), it runs across whole
faculties. "Our" algebra or analysis folks were zero-counters, too.

But it might be incomplete.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> > > Arguably, "zero or more" might be clearer here [...]
> 
> > 1. I said "More precisely: zero or more" in my
> >    second reply to this thread:
> 
> I was mulling over the manual's text, not over yours.
> 
> >      Not to belabor this... but perhaps you're
> >      missing understanding _zero as a number_, in
> >      "number of arguments".  More precisely: zero
> >      or more args.
> 
> I don't know who "you" is in this context: if you
> meant "me" 

As I said, I quoted from my second reply in the thread,
which was to Jean Louis.  The "you" refer to is in that
quoted reply to him.  "You" meant Jean, there.

And the context was "number of arguments".  And as I
pointed out, Elisp has nullary functions: functions
that take zero arguments.  "Any number of arguments"
_means_, for Elisp, "zero or more args" -- "number"
here _must_ include the number zero.  Nothing more.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On Wed, Jan 18, 2023 at 05:27:08PM +0000, Drew Adams wrote:
> > > > Arguably, "zero or more" might be clearer here [...]
> > 
> > > 1. I said "More precisely: zero or more" in my
> > >    second reply to this thread:
> > 
> > I was mulling over the manual's text, not over yours.
> > 
> > >      Not to belabor this... but perhaps you're
> > >      missing understanding _zero as a number_, in
> > >      "number of arguments".  More precisely: zero
> > >      or more args.
> > 
> > I don't know who "you" is in this context: if you
> > meant "me" 
> 
> As I said, I quoted from my second reply in the thread,
> which was to Jean Louis [...]

I see.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [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/

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> > 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.

Are you not reading what I write?  "single _list_
argument".  I'm trying to help you understand the
use of variable-arity functions.

Most languages pass an explicit list of values
instead of a variable number of args, to be able
to act on multiple values.

Folks who find variable arity odd can usually
understand that it's essentially what they're
already used to in the form of passing a list of
values.  That isn't unusual; variable arity is
unusual.  That's why I spoke about instead passing
a _list_ of values.

> > 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. 

See the code I provided.  Passing a list of values
to a unary `foo':

(foo '(3 6 9))
(foo '(2))
(foo ())

Passing multiple values to a variable-arity `foo':

(foo 3 6 9)
(foo 2)
(foo)

Those are different functions.  The idea's similar.
That's all.  The point was to show you how other
languages accomplish the same thing (applying a
function to an arbitrary number of values) - they
use a list.

> > 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?

Don't know and don't care.  It's common in languages
where functions have typed signatures etc.  That's
what you have and do in Haskell, for instance: pass
a list, if you want to act on an arbitrary number of
values.

> > 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.

No idea what wavelength you're on here; sorry.

I was talking about initializing a function that
accumulates - such as Elisp's +.

> Without practical use I can only tell it is capricious decision.

Without using it or understanding it you can
continue to think so, I suppose.

If you want to add four numbers without taking
advantage of (+ 3 6 2 8), then just do so:
(+ 3 (+ 6 (+ 2 8))) or (+ (+ (+ 3 6) 2) 8) or...
Go for it - Lisp won't mind.

> 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.

How about + or * with more than 2 args?  Do you
think allowing that is also useless imagination,
a capricious decision, madness imposed by useless
mathematicians?

If you can see how it can be useful to use + and
* with more than 2 args, then the case for passing
an arbitrary number of args is made.  If your only
problem now is seeing why allowing such generality
should _also_ allow (+ 3) and (+) then I think
we've made some progress.

Submit an enhancement request if you like: Don't
allow + and * (and the like) to accept less than
two args.  See how well that request goes over.

> Otherwise I get idea it was just pecular decision.

_Lisp_ is a peculiar decision all 'round.  Get over
it - that's my suggestion.  Better is to understand
it and put your own thinking in question first, but
if you can't, or don't want to, do that then just
get over it.  I showed you how to code your own
addition function that accepts two or more args.
And it's just as easy to code your own that requires
exactly two.  Roll your own and be happy ever after.

> > 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.

You're really not reading well.  That was in the
context of an addition function that accepts a
single list arg instead of multiple args.  It was
for my apparently unsuccessful attempt to get you
past the "peculiarity" of variable arity.

> It is for adding numbers, not for adding numbers in a list.

Q:  How does one add multiple numbers in a single
    function call?
A1: Pass them in a list argument.
A2: Pass them as multiple arguments.

A2 is possible only in languages that allow
variable arity.  A1, or fiddling with partial
application, is what most languages use.

> Which Emacs Lisp program will break if we demand
> 2 elements for *, - and + ?

Any that uses more than 2 args.  There're thousands
such uses.  Your focusing on the nullary and single
arg cases is _______.  The main use of the variable
arity of these functions is for _2 or more_ values.

The uses of zero or one value are typically for a
base case of a recursion or the limiting case of an
iteration.  Yes, such cases could instead use code
that's a bit more complicated, bottoming out when
getting down to 2 args.  But who would want to need
such bother?  (You, I guess?  Check back later.)
 
> By answering that question we can see where it is usable.

We see where it's usable.  You haven't yet, but I'm
certain you will at some point.

> > 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

??  You're really not reading, are you?

> 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?

Do I think that?  No.  Does anyone?

> If it is about errors, why then we allow / to have 
> error but * not to have error?

Your questions about this have been answered over
and over, by others.  Division and subtraction
are not the same as multiplication and addition.

> For me is not logical this: (apply '* '()) ➜ 1 because I want error to
> tell me that I did not provide arguments for multiplication.

I gave you code to do that.

> 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.

It doesn't sound like you do.

Re: (*) -> 1

[Jean Louis]

Hello Paul,

I suppose you made (*) ➜ 1 function as such, please see and let me
know if you know the reason why you added it.

Too much was told about it on mailing list, but I can't find
reasons. People tried to explain it with mathematics.

Was the reason mathematical set theory? What was reason for your
change in the `*' function back in 2018?

* Drew Adams <drew.adams@oracle.com> [2023-01-18 23:37]:
> See the code I provided.  Passing a list of values
> to a unary `foo':
> 
> (foo '(3 6 9))
> (foo '(2))
> (foo ())
> 
> Passing multiple values to a variable-arity `foo':
> 
> (foo 3 6 9)
> (foo 2)
> (foo)

I understand that idea and understood in first time. 

Only that it does not fit in general context of any function. 

And explanation tries to fit it for every function.

> > Without practical use I can only tell it is capricious decision.
> 
> Without using it or understanding it you can
> continue to think so, I suppose.

And how can I understand if none of participants demonstrated the use?

Not mentioning justifications how somewhere outside of Lisp something
exists theoretically... that outside is not Emacs Lisp.

> > 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.
> 
> How about + or * with more than 2 args?  Do you
> think allowing that is also useless imagination,
> a capricious decision, madness imposed by useless
> mathematicians?

My question was simple. You counter with questions. Deviation from
straight answer does not make it an answer.

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?

It is not a mind boggling question, it is practical question to
understand if there is use of it.

What is mind boggling is that people explain how it must be so,
without showing use for it.

I can make my private functions as I want, I can return funny stuff
like "Doomed", and I can justify it that I don't like raising errors,
or that I have seen game which gave me the idea to return that result.

I believe there is plausible explanation which was not mentioned in
the mailing list, as somebody must have the answer for it.

Trying to explain it by using mathematics outside of Emacs without
showing me use of it does not give me understanding.

I am trying to search to root of it, and I find that function is
defined as this:

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);
}

but back in time it was defined as following:
https://github.com/emacs-mirror/emacs/blob/8f3a2c2659ddee1ae84b4b8bb28f6c388f87fd0f/src/data.c

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)
{
  return arith_driver (Amult, nargs, args);
}

and that was in August 5, 2013, and then by searching commmits, I can
find:

August 28, 2018, it was not there!!!

Does that mean all of explanations by participants were not valid
before that date? 

Then I look at the first time it appeared in Emacs:
https://github.com/emacs-mirror/emacs/blob/fe042e9d15da7863b5beb4c2cc326a62d2c7fccb/src/data.c

Improve arithmetic performance by avoiding bignums until needed.
Also, simplify bignum memory management, fixing some unlikely leaks.
This patch improved the performance of (+ 2 2) by a factor of ten
on a simple microbenchmark computing (+ x 2), byte-compiled,
with x a local variable initialized to 2 via means the byte
compiler could not predict: performance improved from 135 to 13 ns.
The platform was Fedora 28 x86-64, AMD Phenom II X4 910e.
Performance also improved 0.6% on ‘make compile-always’.
* src/bignum.c (init_bignum_once): New function.
* src/emacs.c (main): Use it.
* src/bignum.c (mpz): New global var.
(make_integer_mpz): Rename from make_integer.  All uses changed.
* src/bignum.c (double_to_bignum, make_bignum_bits)
(make_bignum, make_bigint, make_biguint, make_integer_mpz):
* src/data.c (bignum_arith_driver, Frem, Flogcount, Fash)
(expt_integer, Fadd1, Fsub1, Flognot):
* src/floatfns.c (Fabs, rounding_driver, rounddiv_q):
* src/fns.c (Fnthcdr):
Use mpz rather than mpz_initting and mpz_clearing private
temporaries.
* src/bignum.h (bignum_integer): New function.
* src/data.c (Frem, Fmod, Fash, expt_integer):
* src/floatfns.c (rounding_driver):
Use it to simplify code.
* src/data.c (FIXNUMS_FIT_IN_LONG, free_mpz_value):
Remove.  All uses removed.
(floating_point_op): New function.
(floatop_arith_driver): New function, with much of the guts
of the old float_arith_driver.
(float_arith_driver): Use it.
(floatop_arith_driver, arith_driver):
Simplify by assuming NARGS is at least 2.
All callers changed.
(float_arith_driver):
New arg, containing the partly converted value of the next arg.
Reorder args for consistency.  All uses changed.
(bignum_arith_driver): New function.
(arith_driver): Use it.  Do fixnum-only integer calculations
in intmax_t instead of mpz_t, when they fit.
Break out mpz_t calculations into bignum_arith_driver.
(Fquo): Use floatop_arith_driver instead of float_arith_driver,
since the op is known to be valid.
(Flogcount, Fash): Simplify by coalescing bignum and fixnum code.
(Fadd1, Fsub1): Simplify by using make_int.


As I cannot decipher above, does that mean that (*) ➜ 1 was added only
for reason to speed up some C functions in Emacs?

Is that the reason Paul?


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Yuri Khan]

On Thu, 19 Jan 2023 at 16:18, Jean Louis <bugs@gnu.support> wrote:

> Then I look at the first time it appeared in Emacs:
> https://github.com/emacs-mirror/emacs/blob/fe042e9d15da7863b5beb4c2cc326a62d2c7fccb/src/data.c
>
> Improve arithmetic performance by avoiding bignums until needed.
> (floatop_arith_driver, arith_driver):
> Simplify by assuming NARGS is at least 2.
> All callers changed.

> As I cannot decipher above, does that mean that (*) ➜ 1 was added only
> for reason to speed up some C functions in Emacs?

I understand the above as “before, calculation of 0- and 1-argument
sums and products was handled by the generic implementations in
floatop_arith_driver and arith_driver, but it turned out that
detecting those cases early is cheaper”. If you read the version of
arith_driver prior to this change, you will see the initialization of
the accum variable with an identity value according to the operation,
and then doing the binary operation on accum and each successive
argument and storing the intermediate result back into accum.

The actual logic of (+) and (*) for 0- and 1-argument cases did not
change in that commit. You will have to dig deeper into the history if
you want to find who introduced it first.

Re: (*) -> 1

[Anders Munch]

Jean Louis wrote:
> 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?

Yes.  Occurrences of 
	(apply #'* ...)
would fail at an alarming rate.

regards, Anders

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-01-17 05:21]:
> > > The use of `apply', pointed out by Anders, speaks
> > > directly to "any number of arguments".  It applies
> > > a function (e.g. `+') to "any number of arguments",
> > > which are passed as a list.
> > 
> > Any number means also no argument? To me that is not clear.
> 
> That's why I pointed out that _zero is a number_.

That is clear.

> A zero number of args means zero args, which
> means no args.

Aha that is what you mean. Sounds like practical joke with function
descriptions. Though that is not what is expressed like:

* is a built-in function in ‘C source code’.

(* &rest NUMBERS-OR-MARKERS)

Return product of any number of arguments, which are numbers or
markers.

Product of any number of arguments when there are no arguments can't
be 1 -- so function description is logically justified with your
statement, but not consistent, I can't be sure if author intended it
that way how you justify it, due to inconsistency.

> > Any number of arguments is to me that it must be at least one
> > argument, not no argument.
> 
> Zero is a number.  I have zero Ferraris. :-(

Multiply your Ferraris and tell me if you get one in the garage.

> > * is a built-in function in ‘C source code’.
> > (* &rest NUMBERS-OR-MARKERS)
> > Return product of any number of arguments, which are numbers or markers.
> > 
> > But without having arguments, the product is one,
> > which contradicts multiplication how I know it.
> 
> Yes, it's taking a shortcut, supposing that you
> think of a "product" of one arg and a "product"
> of zero args: (* N) -> N, (*) -> 0

Not zero but: (*) ➜ 1 -- we are back to Ferrari.

I don't get it.

> Imagine that you wanted to define a "product" function that works
> with any number of args.  What would _you_ define as its behavior
> (return value) for the zero-args case?  And what would you use for
> the single-arg case?

I expect (*) to tell me that it is error, that arguments are
missing. I learned multiplication in school, we never had impossible
situation of using single argument. As number has to be multiplied by
number. Multiplication table has always 2 arguments.

The manual says like:

 > -- Function: + &rest numbers-or-markers
 >     This function adds its arguments together.  When given no
 >     arguments, ‘+’ returns 0.
1
but I wonder why is that explained in manual and not in docstring.

For now I can only think that it deviates from common multiplication
that requires 2 numbers for the reason to be used in Lisp functions
such as `apply' or others, just that I can't yet confirm it if that is
designed for that particular reason.

(apply '* nil) ➜ 1

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Yuri Khan]

On Tue, 17 Jan 2023 at 22:06, Jean Louis <bugs@gnu.support> wrote:

> I learned multiplication in school, we never had impossible
> situation of using single argument. As number has to be multiplied by
> number. Multiplication table has always 2 arguments.

I think we are getting somewhere. We have a common frame of reference:
School multiplication.

School defines multiplication as a binary operator, that is, taking
two arguments.

School then says multiplication is associative. That is, it does not
matter which order you do it: (a * b) * c = a * (b * c).

Because of this, it makes sense to talk about the product of a list of
numbers: a * b * c * d * e. It has the same value whether you
interpret it as (((a * b) * c) * d) * e or a * (b * (c * (d * e))).
You can even say there is a multiplication operator that takes five
arguments. Or four arguments. Or three. Or any natural number of
arguments.

Division, on the other hand, is not associative. If you say a / b / c,
people give you a funny look and ask to please clarify whether you
mean (a / b) / c or a / (b / c).

Time passes. You are now at a university. They tell you zero is a
natural number.

You recall that funny multiplication operator that takes a natural
number of arguments, which has a sound definition due to binary
multiplication being associative. Since zero is a natural number, what
should be the product of a zero length list of arguments?

School had also said multiplying by 1 has the same effect as not
multiplying at all. That is, a * 1 = a. Also, school had said that for
every non-zero a, if a * b = a * c, then b = c, hadn’t it? Somewhere
around the time you learned to solve equations. It was called
canceling.

Let’s look at that a * 1 = a. On the left, we have the product of two
numbers. On the right, we have one number, and if we squint at it like
this, we can say it’s a product of one number. So these are two
products that have a common element. We can cancel it. (Assuming it’s
not zero. But we know that a * 1 = a holds for any a, including
non-zeros.)

Now, on the left, we have 1. On the right… we have a product of no
numbers. And there is an equality sign in between.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

Thanks, I could follow the previous.

* Yuri Khan <yuri.v.khan@gmail.com> [2023-01-17 19:00]:
> School had also said multiplying by 1 has the same effect as not
> multiplying at all. 

Not in absence of factors!

> That is, a * 1 = a. Also, school had said that for every non-zero a,
> if a * b = a * c, then b = c, hadn’t it? Somewhere around the time
> you learned to solve equations. It was called canceling.

I can see how you try to make it logic, but I do not ask for
mathematics out of context of Lisp. I am asking why is in Lisp so?
Common Lisp, Emacs Lisp, Guile, Newlisp, elk, with difference that
Emacs Lisp (-) ➜ 0 but in others arguments missing, with Picolisp
where (-) ➜ nil, (*) ➜ nil, (+) ➜ nil, but `apply' works.

Why would Emacs Lisp have (-) ➜ 0 and other Lisps not?

If `apply' works in Picolisp without problem, is the usage of such
functions really the reason for yielding identity for (*), (+), (-)?

> Let’s look at that a * 1 = a. On the left, we have the product of two
> numbers. On the right, we have one number, and if we squint at it like
> this, we can say it’s a product of one number. So these are two
> products that have a common element. We can cancel it. (Assuming it’s
> not zero. But we know that a * 1 = a holds for any a, including
> non-zeros.)
> 
> Now, on the left, we have 1. On the right… we have a product of no
> numbers. And there is an equality sign in between.

I have followed your guidance, but your guidance speaks of existence
of something to cancel, and I speak of absence of arguments!

Not even identity theory does not speak of identity elements in
absence of everyting else!

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> > > Any number of arguments is to me that it must be at least one
> > > argument, not no argument.
> > 
> > Zero is a number.  I have zero Ferraris. :-(
>
> Multiply your Ferraris and tell me if you get one in the garage.

OTOH, multiplying someone's 2 Ferraris with his neighbor's 3 Ferraris
giving 6 Ferraris makes perfectly sense, of course.

Michael.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Yuri Khan]

On Tue, 17 Jan 2023 at 23:06, Michael Heerdegen
<michael_heerdegen@web.de> wrote:

> OTOH, multiplying someone's 2 Ferraris with his neighbor's 3 Ferraris
> giving 6 Ferraris makes perfectly sense, of course.

Hey! Dimension analysis police! That’s 6 *square* Ferraris for you.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Tue, Jan 17, 2023 at 05:05:33PM +0100, Michael Heerdegen wrote:
> Jean Louis <bugs@gnu.support> writes:
> 
> > > > Any number of arguments is to me that it must be at least one
> > > > argument, not no argument.
> > > 
> > > Zero is a number.  I have zero Ferraris. :-(
> >
> > Multiply your Ferraris and tell me if you get one in the garage.
> 
> OTOH, multiplying someone's 2 Ferraris with his neighbor's 3 Ferraris
> giving 6 Ferraris makes perfectly sense, of course.

It's Ferraris squared (physicist here ;-)

But then, yes.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 19:08]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > > > Any number of arguments is to me that it must be at least one
> > > > argument, not no argument.
> > > 
> > > Zero is a number.  I have zero Ferraris. :-(
> >
> > Multiply your Ferraris and tell me if you get one in the garage.
> 
> OTOH, multiplying someone's 2 Ferraris with his neighbor's 3 Ferraris
> giving 6 Ferraris makes perfectly sense, of course.

I guess it is joke on the joke with a pinch of irony. But
multiplication of something in existence like some Ferraris in
existence is not really my objection, or question.

There is notion that out of of nothing (which is not `nil') being
argument, in absence of factors for multiplication, we get result of
one. 

(*) ➜ 1

According to above expression, the empty garage must yield with
Ferrari, provided multiplication is done by Emacs Lisp or similar, but
not with PicoLisp (it yields NIL). And for two empty garages, if
operation is applied on each of them:

(*) ➜ 1
(*) ➜ 1

We will get total of 2 Ferraris out of nothing.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> (*) ➜ 1
> (*) ➜ 1
>
> We will get total of 2 Ferraris out of nothing.

And with (concat) we get an empty string in the garage out of nothing.

(*) and (concat) obviously are not useful in conjunction with Ferraris.
There is no interpretation in terms of Ferraris.

We don't want to constrain math to things that have interpretations in
Ferrari collections.

Michael.

Re: (*) -> 1

[Óscar Fuentes]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Jean Louis <bugs@gnu.support> writes:
>
>> (*) ➜ 1
>> (*) ➜ 1
>>
>> We will get total of 2 Ferraris out of nothing.
>
> And with (concat) we get an empty string in the garage out of nothing.
>
> (*) and (concat) obviously are not useful in conjunction with Ferraris.
> There is no interpretation in terms of Ferraris.
>
> We don't want to constrain math to things that have interpretations in
> Ferrari collections.

This is not about Mathematics, it is about notation, that means,
convention, that means, convenience.

In other programming languages an expression such as "+ 2" would yield a
partially applied function:

let f = + 2
f 5
-> 7

Lisp (or some implementations of it) went the route of "+ sums a list of
numbers." That's fine, and in that sense having (+) -> 1 is reasonable,
but there is nothing in Mathematics that says that it must be so instead
of yielding partially applied function, or simply throwing an error
message. Lisp's option is a consequence of its syntax (notation).

Re: (*) -> 1

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [2023-01-17 21:13]:
> This is not about Mathematics, it is about notation, that means,
> convention, that means, convenience.
> 
> In other programming languages an expression such as "+ 2" would yield a
> partially applied function:
> 
> let f = + 2
> f 5
> -> 7
> 
> Lisp (or some implementations of it) went the route of "+ sums a list of
> numbers." That's fine, and in that sense having (+) -> 1 is reasonable,
> but there is nothing in Mathematics that says that it must be so instead
> of yielding partially applied function, or simply throwing an error
> message. Lisp's option is a consequence of its syntax (notation).

Okay, but in C language definition of function `+' I see that if no
arguments are supplied the result shall be 0, or for `*' the result
shall be 1. So I see it from authoring side being something of
importance, not from syntax side, as author, programmer, maybe
Stallman, he could as well hande those functions with error, there was
some reason why they deliberately explicitly decided to provide
identity in absence of any arguments.

At least I feel closer to solution after looking at "variadic
functions".

In the sense of minimizing errors, I have no example, is hard to
understand that is the reason. In fact I need errors with many
functions, as they are useful.

I would not like really in my mathematical functions to get result 1
if I for example forgot to write something, instead of writing:

(setq hours 10) ➜ 10
(setq interval 2) ➜ 2
(setq waiting-time 2) ➜ 2
(setq my-appointment (+ hours (* interval waiting-time))) ➜ 14
so if I write by mistake following:
(setq my-appointment (+ hours (*))) ➜ 11

I would not like that mistake being there, as that would by my typo,
and I need error, and not silent ignorance that I missed to write some
arguments. 

I have given one example why and how I understand that function `*'
would be more useful to yield the erorr, then 1.

What I am searching is why is (*) function useful to yield 1 in some
example. Do you have it? Can you maybe think of one?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Óscar Fuentes]

Jean Louis <bugs@gnu.support> writes:

> * Óscar Fuentes <ofv@wanadoo.es> [2023-01-17 21:13]:
>> This is not about Mathematics, it is about notation, that means,
>> convention, that means, convenience.
>> 
>> In other programming languages an expression such as "+ 2" would yield a
>> partially applied function:
>> 
>> let f = + 2
>> f 5
>> -> 7
>> 
>> Lisp (or some implementations of it) went the route of "+ sums a list of
>> numbers." That's fine, and in that sense having (+) -> 1 is reasonable,
>> but there is nothing in Mathematics that says that it must be so instead
>> of yielding partially applied function, or simply throwing an error
>> message. Lisp's option is a consequence of its syntax (notation).
>
> Okay, but in C language definition of function `+' I see that if no
> arguments are supplied the result shall be 0, or for `*' the result
> shall be 1. So I see it from authoring side being something of
> importance, not from syntax side, as author, programmer, maybe
> Stallman, he could as well hande those functions with error, there was
> some reason why they deliberately explicitly decided to provide
> identity in absence of any arguments.
>
> At least I feel closer to solution after looking at "variadic
> functions".
>
> In the sense of minimizing errors, I have no example, is hard to
> understand that is the reason. In fact I need errors with many
> functions, as they are useful.
>
> I would not like really in my mathematical functions to get result 1
> if I for example forgot to write something, instead of writing:
>
> (setq hours 10) ➜ 10
> (setq interval 2) ➜ 2
> (setq waiting-time 2) ➜ 2
> (setq my-appointment (+ hours (* interval waiting-time))) ➜ 14
> so if I write by mistake following:
> (setq my-appointment (+ hours (*))) ➜ 11
>
> I would not like that mistake being there, as that would by my typo,
> and I need error, and not silent ignorance that I missed to write some
> arguments. 
>
> I have given one example why and how I understand that function `*'
> would be more useful to yield the erorr, then 1.
>
> What I am searching is why is (*) function useful to yield 1 in some
> example. Do you have it? Can you maybe think of one?

I think your confusion comes from an assumption that everybody else on
this conversation is blind to, in the sense that nobody (I didn't read
most of the thread, though) didn't explicitly stated it:

+ in Elisp is not the "plus" operation that we all know (the same C uses
and school children use.) + in Elisp is not the binary operation, it is
the summatory operator, which takes a list of arguments and returns the
sum of them all.

In that sense, maybe you can see more naturally that "the sum of nothing
is zero." This makes possible to apply the + (summatory!) operator to
any list of numbers, including the empty list.

As for the * operator, it is the same case as +, with the caveat of not
being so obvious that the multiplication of and empty list of numbers is
1. Here we choose convenience: as it is interesting to have all those
n-adic operators work for an arbitrary number of arguments (including 0)
we chose to return the "identity element" of the underlaying operation.

The "identity element" e for a binary operation $ is the element that
yields

e $ n -> n
n $ e -> n

for all n. So for the logior case in your other message 0 is the
identity element, as (logior n 0) -> (logior 0 n) -> n for all n.

The language designers pursue convenience and consistency and take
decisions based on some sense of what is "natural". Hence if we see as
reasonable that the summatory of an empty list of arguments is zero (the
identity element for summation) and we want for as much operators as
possible to work on empty lists, we also choose to return the empty
element for the underlaying operation of the operator on those cases.
There are more supporting "reasons" for doing that, such as:

(* 1 1 1) -> 1
(* 1 1) -> 1
(* 1) -> we want it to act as being equivalent to (* 1 1).
(*) -> same.

Re: (*) -> 1

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [2023-01-17 22:06]:
> I think your confusion comes from an assumption that everybody else on
> this conversation is blind to, in the sense that nobody (I didn't read
> most of the thread, though) didn't explicitly stated it:
> 
> + in Elisp is not the "plus" operation that we all know (the same C uses
> and school children use.) + in Elisp is not the binary operation, it is
> the summatory operator, which takes a list of arguments and returns the
> sum of them all.
> 
> In that sense, maybe you can see more naturally that "the sum of nothing
> is zero." This makes possible to apply the + (summatory!) operator to
> any list of numbers, including the empty list.

Do you mean with "C uses" that "C language uses"?

> The language designers pursue convenience and consistency and take
> decisions based on some sense of what is "natural". Hence if we see as
> reasonable that the summatory of an empty list of arguments is zero (the
> identity element for summation) and we want for as much operators as
> possible to work on empty lists, we also choose to return the empty
> element for the underlaying operation of the operator on those cases.
> There are more supporting "reasons" for doing that, such as:

OK I understand it as hypothesis, though is there reference that it
was that way?

Still missing the use case.

I see it this way:

- For this I don't see clearly why we are supposed to imagine 1 when
  two factors are required for multiplication. I would rather like
  error for missing argument. 

(* 2) ➜ 2

- Following makes no sense at all if we can't find actual usage for
  it.

(*) ➜ 1

When we talk of identity elements, then I read here:
https://en.wikipedia.org/wiki/Additive_identity

In mathematics, the additive identity of a set that is equipped with
the operation of addition is an element which, when added to any
element x in the set, yields x.

But we have here case of "not adding additive identity", because is
not there: (+)

I would say that (+ 2 0) ➜ 2 demonstrates the additive identity. It
has to be added to other elements to be additive identity, it does not
spring out of nothing.  In that reference they speak of showing the
identity first, not "without showing it at all", if nothing is there,
then nothing was subject of addition, and so there is no result with
additive identity. 

Similarly see here: https://brilliant.org/wiki/identity-element/
where it says: "An identity element in a set is an element that is
special with respect to a binary operation on the set: when an
identity element is paired with any element via the operation, it
returns that element"

So there must be elements in first place to say that something is
identity element. 

We speak of absence of any elements. One less important question is
why author of Lisp decided to yield 1 for (*), more important
questions is of the use of it. 

Practically I found one use during sketching stage of programs, just
to write it there as preliminary placeholders, like:

(* (*) (*)) then in few minutes it is then expanded to:

(* (* specific-gravity cubic-meter) (* ))

then to be expanded to:

(* (* specific-gravity cubic-meter) (* excavator-cycles hour))

Apart from few references on Internet we talked about, I cannot find
uses for it, or purpose, it seem difficult.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Óscar Fuentes]

Jean Louis <bugs@gnu.support> writes:

> * Óscar Fuentes <ofv@wanadoo.es> [2023-01-17 22:06]:
>> I think your confusion comes from an assumption that everybody else on
>> this conversation is blind to, in the sense that nobody (I didn't read
>> most of the thread, though) didn't explicitly stated it:
>> 
>> + in Elisp is not the "plus" operation that we all know (the same C uses
>> and school children use.) + in Elisp is not the binary operation, it is
>> the summatory operator, which takes a list of arguments and returns the
>> sum of them all.
>> 
>> In that sense, maybe you can see more naturally that "the sum of nothing
>> is zero." This makes possible to apply the + (summatory!) operator to
>> any list of numbers, including the empty list.
>
> Do you mean with "C uses" that "C language uses"?

Yes.

Please keep in mind that * in Elisp is not the same as * in C. Elisp
provides a variadic function, while C provides a binary operator.

> We speak of absence of any elements. One less important question is
> why author of Lisp decided to yield 1 for (*), more important
> questions is of the use of it. 
>
> Practically I found one use during sketching stage of programs, just
> to write it there as preliminary placeholders, like:
>
> (* (*) (*)) then in few minutes it is then expanded to:
>
> (* (* specific-gravity cubic-meter) (* ))
>
> then to be expanded to:
>
> (* (* specific-gravity cubic-meter) (* excavator-cycles hour))
>
> Apart from few references on Internet we talked about, I cannot find
> uses for it, or purpose, it seem difficult.

So let's borrow an example from a previous post from Michael. Let's
suppose you want to write a function that takes a list with the factors
that represent a sequence of annual interest rates (so 1.05 is 5%, etc.)
You want that function to return the equivalent rate for the period
comprising those years: R1 * R2 * R3...

A possible implementation would be:

(defun equiv-rate (yearly-rates)
  (apply '* yearly-rates))

You use that value to calculate how much money you get from a deposit
after those years.

(defun money-after-years (initial-deposit yearly-rates)
  (* initial-deposit (equiv-rate yearly-rates)))
  
But what happens if yearly-rates contains less than 2 elements? Let's
see:

If it contains just one element (one year) the result is the rate of
that year.

If it contains zero elements (zero years) the result shall be 1,
otherwise money-after-years would be wrong: if you make a deposit, it
must be the same after 0 years!

So you adapt equiv-rate:

(defun equiv-rate (yearly-rates)
  (case (length yearly-rates)
    (0 1)
    (1 (car yearly-rates))
    (otherwise (apply '* (yearly-rates)))))

But as it happens in Elisp, you can use the first, simple version of
equiv-rate just fine, because the * variadic function already does the
right thing for you.

RE: [External] : Re: (*) -> 1

[Drew Adams]

> I see it this way:
> - For this I don't see clearly why we are supposed to imagine 1 when
>   two factors are required for multiplication. I would rather like
>   error for missing argument.

I explained, and showed code, for how you can
do this yourself - create your own `my-times'
function that _requires_ exactly two args.  I
showed it for addition, not multiplication,
but the code is the same.

And I showed you how you could code an Elisp
product function equivalent to Elisp's *,
based only on your `my-times' function (which
requires two args).  Again, I showed it for
addition/summation, not multiplication/product,
but the code is the same.

That latter code was just to show you the
relation between the two - expressed in Elisp.
You don't want/like variable-arity sum/product
functions, for some reason.  You can use your
own, binary ones - you need never use + or *.

I really suggest you take a look at the code
and my explanation.  I think that will help you
understand all that you're so far confused about,
wondering about, asking about, or interested in.

Elisp doesn't bother defining binary functions
for adding and multiplying.  Instead it defines
variable-arity versions (summation and product,
if you prefer those names).

It does so _because those are more general_ - you
can use them with any number of args - including
two.  But if _you_ want binary versions, which
raise an error if other than two args are passed,
you can easily get that, with no cost.  QED.

There's really nothing more to say.  The Elisp
doc is fine here - it's correct, sufficient, and
clear to just say that + and * take "any number
of arguments".

And readers should understand that "any number
of args" for an Elisp function includes _zero_
args.  Why?  Because Elisp allows for nullary
functions: it allows functions to take zero args.

You seemed to think I was practical-joking when
pointing out that the doc includes the zero-args
case when it says "any number", _because_ zero
can be the _number_ of args:

> > A zero number of args means zero args,
> > which means no args.
>
> Aha that is what you mean. Sounds like
> practical joke with function descriptions.

Nope; not a joke.

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> I have given one example why and how I understand that function `*'
> would be more useful to yield the erorr, then 1.

Ok, one math example.

  -----        -----          -----
   | |          | |            | | 
   | | f(k)  =  | | f(k)  *    | |  f(k)
   | |          | |            | | 
m < k < n    m < k < n      m < k < n
              k prime      k not prime

Maybe the function f behaves very differently for primes and non-primes
so it's easier to compute the product like that.

But if an empty product would not be defined the whole formula would
only make sense if there are primes between n and m, and the
transformation would not be valid in the general case (since one would
always have to test for primes between n and m - for no gain).

Similar things "happen" in programming.

Michael.

Re: (*) -> 1

[Michael Heerdegen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> In other programming languages an expression such as "+ 2" would yield a
> partially applied function:
>
> let f = + 2
> f 5
> -> 7

The "dual" problem can also exist in this interpretation of notation,
though:

Would a partial application of `*' to no arguments result in a function
multiplying the product of the arguments (with 1), or would it result in
a function raising an error?  What would this function applied to no
arguments return?

What would the partial application of `-' to a number return when
applied to no arguments?  Etc.

Michael.

Re: (*) -> 1

[Óscar Fuentes]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> In other programming languages an expression such as "+ 2" would yield a
>> partially applied function:
>>
>> let f = + 2
>> f 5
>> -> 7
>
> The "dual" problem can also exist in this interpretation of notation,
> though:
>
> Would a partial application of `*' to no arguments result in a function
> multiplying the product of the arguments (with 1), or would it result in
> a function raising an error?  What would this function applied to no
> arguments return?

The function either has all arguments satisfied (and then it is
computed) or not (and then it is a partially applied function). So `f'
in the previous example:

f
-> f

* 3
-> * 3

> What would the partial application of `-' to a number return when
> applied to no arguments?  Etc.

I'm not sure I understand this question. Maybe this:

let f = - 5
f 3
-> 2

or

let f = - _ 3  ;; `_' stands for "absent argument"
f 5
-> 2

The languages that use the concept of partially applied function usually
have no support for variadic functions, so the duality problem you refer
to is not an issue.

Re: (*) -> 1

[Michael Heerdegen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> The languages that use the concept of partially applied function usually
> have no support for variadic functions, so the duality problem you refer
> to is not an issue.

Interesting.  I do not know many other languages.

I see your point now: while I wrote about the procedure of finding an
interpretation [of the technical or mathematical semantics of a formula]
in the real world [this is what had been ongoing: Ferraris etc], you
mention that even the technical/theoretical semantics of a formula like
(*) can be different.  This is an interesting point, especially since
terms like "right" and "wrong" had been used.

Although I think the "meaning" of the expression (*) in Elisp is clear,
it describes a mathematical term, so the question, asked specifically
for Elisp, has to be answered using the mathematical background.  In my
understanding the OP asked specifically about the empty algebraic
product.


Michael.

Re: (*) -> 1

[Óscar Fuentes]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> The languages that use the concept of partially applied function usually
>> have no support for variadic functions, so the duality problem you refer
>> to is not an issue.
>
> Interesting.  I do not know many other languages.
>
> I see your point now: while I wrote about the procedure of finding an
> interpretation [of the technical or mathematical semantics of a formula]
> in the real world [this is what had been ongoing: Ferraris etc], you
> mention that even the technical/theoretical semantics of a formula like
> (*) can be different.  This is an interesting point, especially since
> terms like "right" and "wrong" had been used.
>
> Although I think the "meaning" of the expression (*) in Elisp is clear,
> it describes a mathematical term, so the question, asked specifically
> for Elisp, has to be answered using the mathematical background.  In my
> understanding the OP asked specifically about the empty algebraic
> product.

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.

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.

Re: (*) -> 1

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

On Wed, Jan 18, 2023 at 08:50:07AM +0100, Óscar Fuentes wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > Óscar Fuentes <ofv@wanadoo.es> writes:
> >
> >> The languages that use the concept of partially applied function usually
> >> have no support for variadic functions, so the duality problem you refer
> >> to is not an issue.
> >
> > Interesting.  I do not know many other languages.
> >
> > I see your point now: while I wrote about the procedure of finding an
> > interpretation [of the technical or mathematical semantics of a formula]
> > in the real world [this is what had been ongoing: Ferraris etc], you
> > mention that even the technical/theoretical semantics of a formula like
> > (*) can be different.  This is an interesting point, especially since
> > terms like "right" and "wrong" had been used.
> >
> > Although I think the "meaning" of the expression (*) in Elisp is clear,
> > it describes a mathematical term, so the question, asked specifically
> > for Elisp, has to be answered using the mathematical background.  In my
> > understanding the OP asked specifically about the empty algebraic
> > product.
> 
> 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).

> 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.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: (*) -> 1

[Óscar Fuentes]

<tomas@tuxteam.de> 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.

Re: (*) -> 1

[Michael Heerdegen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Even a programmer can't assume that associativity and commutativity
> can be used on a long, finite, sum.

As long as it's a sum, of course can a programmer assume that.

> 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.

No - the result of "1" is surely related to mathematics.  It comes from
the mathematical interpretation of the term (*) as empty product.

You can interpret it differently, but the convention is the same and
there for the same reason as the same convention for the empty product
in math.

Michael.

Re: (*) -> 1

[Óscar Fuentes]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Even a programmer can't assume that associativity and commutativity
>> can be used on a long, finite, sum.
>
> As long as it's a sum, of course can a programmer assume that.

Of course not! Otherwise your numerical simulation can go very wrong :-)

(hint: numbers in computers are approximate, adding small numbers to
large numbers is a bad idea.)

>> 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.
>
> No - the result of "1" is surely related to mathematics.  It comes from
> the mathematical interpretation of the term (*) as empty product.

Sure.

> You can interpret it differently, but the convention is the same and
> there for the same reason as the same convention for the empty product
> in math.

Sure^2. I was talking about _why_ (*) and (* a) are supported in Elisp.
Once the language designer chose to support those expressions and
decided that they must return a number (instead of something else like a
partially applied function) the value they shall return comes from the
properties of the underlying operation, of course.

Re: (*) -> 1

[Andreas Eder]

On Mi 18 Jan 2023 at 15:07, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> Even a programmer can't assume that associativity and commutativity
>>> can be used on a long, finite, sum.
>>
>> As long as it's a sum, of course can a programmer assume that.
>
> Of course not! Otherwise your numerical simulation can go very wrong :-)
>
> (hint: numbers in computers are approximate, adding small numbers to
> large numbers is a bad idea.)

Only floating point numbers. Integers are exact and in lisps like elisp
there is no artificial size limit.

'Andreas

Re: (*) -> 1

[Óscar Fuentes]

Andreas Eder <a_eder_muc@web.de> writes:

> On Mi 18 Jan 2023 at 15:07, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>
>>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>>
>>>> Even a programmer can't assume that associativity and commutativity
>>>> can be used on a long, finite, sum.
>>>
>>> As long as it's a sum, of course can a programmer assume that.
>>
>> Of course not! Otherwise your numerical simulation can go very wrong :-)
>>
>> (hint: numbers in computers are approximate, adding small numbers to
>> large numbers is a bad idea.)
>
> Only floating point numbers.

Which proves my point :-) And you say "only" as if floating point
numbers were rarely used.

> Integers are exact and in lisps like elisp
> there is no artificial size limit.

If your calculation consists on adding arbitrary precision integers,
*that's* a rarity. If your calculation adds fixed-width integers (which
includes platform integers), you definitely need to worry about order of
terms.

Re: (*) -> 1

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [2023-01-18 17:09]:
> Sure^2. I was talking about _why_ (*) and (* a) are supported in Elisp.
> Once the language designer chose to support those expressions and
> decided that they must return a number (instead of something else like a
> partially applied function) the value they shall return comes from the
> properties of the underlying operation, of course.

OK and I understood that somebody decided to include that.

Why did they decide to include it?

Do you think it is only for `apply' reasons?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 20:54]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > (*) ➜ 1
> > (*) ➜ 1
> >
> > We will get total of 2 Ferraris out of nothing.
> 
> And with (concat) we get an empty string in the garage out of
> nothing.

And why?

(concat) ➜ ""

Is it mathematical convention?

Is it maybe just programming convention to minimize errors like we
mentioned it?

In case of `concat' I can understand that (concat nil) ➜ "" is useful,
that is clear. Then in that sense I can also understand (concat) ➜ ""
being useful as function need not be programmed to say there are no
arguments, but simply accepts any arguments and at least delivers ""
for empty list, even though for list it gives error (concat '("ok"
"there"))

So my understanding that it is for purpose of minimizing errors is in
doubt, as for empty list it gives string, but for non-empty list it
can't handle it.

Then is hard to understand why is it convenient this:
(-) ➜ 0
or
(+) ➜ 0

but not this, where:

(1-) yields with error, and why not -1?
(1+) yields with error, and why not 1?

I read in manual:

 -- Function: logior &rest ints-or-markers
     This function returns the bitwise inclusive OR of its arguments:
     the Nth bit is 1 in the result if, and only if, the Nth bit is 1 in
     at least one of the arguments.  If there are no arguments, the
     result is 0, which is an identity element for this operation.  If
     ‘logior’ is passed just one argument, it returns that argument.

but nowhere else is "identity element" mentioned, so I still look for
reasons why is identity element returned.

To minimize the error? For that information to be acceptable I would
like to find example of minimization of error. It seem hard to find
it, even though it is attributed as being "handy" and "convenient" on
Internet. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Yes, it's taking a shortcut, supposing that you
> think of a "product" of one arg and a "product"
> of zero args: (* N) -> N, (*) -> 0
>
> But it's fairly common, for programmers at least,
> to consider a "product" function as accepting any
> number of arguments (or accepting a single list
> of any number of elements).

n^0 = 1.  n^0 can be interpreted as an empty product of factors n.

n*0 = 0.  n*0 can be interpreted as an empty sum of summands n.

That's all trivial stuff and used all the time - nobody would ever say
that (* 3 0) ==> 0 is wrong or want to document this case specially.

(+) and (*) are not very different, just a bit less often used in
practice.

Michael.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Rudolf Adamkovič <salutis@me.com> [2023-01-15 23:27]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> (+) ➜ 0
> >
> > Why? It is wrong.
> 
> In Lisp, the `+' operator returns the sum of the additive identity with all of
> its arguments.  The additive identity equals zero and you provided zero
> arguments.  Hence, you get the additive identity.

Send me references on what is additive identity.

Though that it is so, it does not answer why is it so.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

Jean Louis wrote:

>> In Lisp, the `+' operator returns the sum of the additive
>> identity with all of its arguments. The additive identity
>> equals zero and you provided zero arguments. Hence, you get
>> the additive identity.
>
> Send me references on what is additive identity.

https://en.wikipedia.org/wiki/Identity_element

> Though that it is so, it does not answer why is it so.

So that a + 0 = a

And for multiplication 1a = a so there, the identity element
is 1.

There is also an identity matrix and so on.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On Mon, Jan 16, 2023 at 12:08:33AM +0300, Jean Louis wrote:
> * Rudolf Adamkovič <salutis@me.com> [2023-01-15 23:27]:
> > Jean Louis <bugs@gnu.support> writes:
> > 
> > >> (+) ➜ 0
> > >
> > > Why? It is wrong.
> > 
> > In Lisp, the `+' operator returns the sum of the additive identity with all of
> > its arguments.  The additive identity equals zero and you provided zero
> > arguments.  Hence, you get the additive identity.
> 
> Send me references on what is additive identity.

Identity element [0] as defined in group theory [1].

The association of 0 with + and 1 with * runs deeper in maths
than you think.

> Though that it is so, it does not answer why is it so.

Those are, of course, conventions. As whether the natural
numbers begin with 0 or 1. But the above is, AFAIK, most
widespread among mathematicians, wheter the latter is not.

Cheers

[0] https://en.wikipedia.org/wiki/Identity_element
[1] https://en.wikipedia.org/wiki/Group_theory

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2023-01-16 09:11]:
> Identity element [0] as defined in group theory [1].
> 
> The association of 0 with + and 1 with * runs deeper in maths
> than you think.
> 
> > Though that it is so, it does not answer why is it so.
> 
> Those are, of course, conventions. As whether the natural
> numbers begin with 0 or 1. But the above is, AFAIK, most
> widespread among mathematicians, wheter the latter is not.

Thanks. 

I could see reference that identity element is the one that would not
change the other elements if the operation would be applied.

This alone makes sense.

But it does not make sense why somebody have put it in Lisp. Do you
know? 

I did not find any references by using Duckduckgo.

(*) ➜ 1
(+) ➜ 0
(/) Wrong number of arguments: /
(-) ➜ 0

The question why is not yet clear to me. Why is it in Lisp so?

Why not then for `/' as well? Is it not possible?

What is practical use of teaching functions to spit it identity
element instead of doing "wrong number of arguments" just as for
division?

It is not explained in Emacs Lisp manual.

If function `*' should without arguments return identity element by
mathematical terminology, that is not explained. 

Then I see in Guile:

(*) ➜ 1
(-) Wrong number of arguments to -
(+) ➜ 0
(/) Wrong number of arguments to /

CLISP:

(-) EVAL: too few arguments given to -: (-)
(*) ➜ 1
(+) ➜ 0

Why Emacs Lisp returns 0 for (-) and CLISP and Guile not?

Finally, what is the actual use of it?


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Yuri Khan]

On Mon, 16 Jan 2023 at 17:17, Jean Louis <bugs@gnu.support> wrote:

> (*) ➜ 1
> (+) ➜ 0
> (/) Wrong number of arguments: /
> (-) ➜ 0
>
> The question why is not yet clear to me. Why is it in Lisp so?

Subtraction and division are not monoid operations. As such, they do
not have an associated identity value.

They also choose to handle the single argument case specially: (- x)
is equivalent to (- 0 x) and (/ x) is equivalent to (/ 1 x).

Making (/) return the multiplicative identity would be consistent though.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2023-01-16 13:43]:
> On Mon, 16 Jan 2023 at 17:17, Jean Louis <bugs@gnu.support> wrote:
> 
> > (*) ➜ 1
> > (+) ➜ 0
> > (/) Wrong number of arguments: /
> > (-) ➜ 0
> >
> > The question why is not yet clear to me. Why is it in Lisp so?
> 
> Subtraction and division are not monoid operations. As such, they do
> not have an associated identity value.

Why then substraction has associated identity value in Emacs Lisp?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

tomas wrote:

> https://en.wikipedia.org/wiki/Identity_element

I have sent this link several times, don't know why my posts
don't appear ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Tue, Jan 17, 2023 at 05:06:19AM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> > https://en.wikipedia.org/wiki/Identity_element
> 
> I have sent this link several times, don't know why my posts
> don't appear ...

They seem to do. Just a bit later. And in bunches. As if there
was a Nagle algorithm to your posts.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Emanuel Berg]

tomas wrote:

>>> https://en.wikipedia.org/wiki/Identity_element
>> 
>> I have sent this link several times, don't know why my
>> posts don't appear ...
>
> They seem to do. Just a bit later. And in bunches. As if
> there was a Nagle algorithm to your posts.

  [A] means of improving the efficiency of TCP/IP networks by
  reducing the number of packets that need to be sent [...]
 
https://en.wikipedia.org/wiki/Nagle%27s_algorithm

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Nick Dokos]

<tomas@tuxteam.de> writes:

> On Mon, Jan 16, 2023 at 12:08:33AM +0300, Jean Louis wrote:
>> * Rudolf Adamkovič <salutis@me.com> [2023-01-15 23:27]:
>> > Jean Louis <bugs@gnu.support> writes:
>> > 
>> > >> (+) ➜ 0
>> > >
>> > > Why? It is wrong.
>> > 
>> > In Lisp, the `+' operator returns the sum of the additive identity with all of
>> > its arguments.  The additive identity equals zero and you provided zero
>> > arguments.  Hence, you get the additive identity.
>> 
>> Send me references on what is additive identity.
>
> Identity element [0] as defined in group theory [1].
>
> The association of 0 with + and 1 with * runs deeper in maths
> than you think.
>
>> Though that it is so, it does not answer why is it so.
>
> Those are, of course, conventions. As whether the natural
> numbers begin with 0 or 1. But the above is, AFAIK, most
> widespread among mathematicians, wheter the latter is not.
>
> Cheers
>
> [0] https://en.wikipedia.org/wiki/Identity_element
> [1] https://en.wikipedia.org/wiki/Group_theory

The "empty sum" and "empty product" conventions are described in the
corresponding articles in Wikipedia too - they might help:

   https://en.wikipedia.org/wiki/Empty_sum
   https://en.wikipedia.org/wiki/Empty_product
   
-- 
Nick

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Nick Dokos <ndokos@gmail.com> [2023-01-17 19:27]:
> The "empty sum" and "empty product" conventions are described in the
> corresponding articles in Wikipedia too - they might help:
> 
>    https://en.wikipedia.org/wiki/Empty_sum
>    https://en.wikipedia.org/wiki/Empty_product

Thanks much.

I understand that "summation" is not equal to "addition" as summation
is the addition of a sequence of any kind of numbers, called addends
or summands; the result is their sum or total:
https://en.wikipedia.org/wiki/Summation

Then back to: https://en.wikipedia.org/wiki/Empty_sum
where it says:

In mathematics, an empty sum, or nullary sum,[1] is a summation where
the number of terms is zero. The natural way to extend non-empty
sums[2] is to let the empty sum be the additive identity. 

Basically function `+' deals with summation, not with addition. But
that is conclusion I can draw alone with help of your references,
without confirmation by docstring, manual or some references.

Though I do not understand why it has to deal with summation, and not
straight with addition? What is use in Lisp?

In this other reference: https://en.wikipedia.org/wiki/Empty_product
the issue with Lisp is mentioned, and we can read, that in many
programming languages it is so, like in Python, Lisp, but in Perl is
not so, then it says:

Multiplication is an infix operator and therefore a binary operator,
complicating the notation of an empty product. Some programming
languages handle this by implementing variadic functions. For example,
the fully parenthesized prefix notation of Lisp languages gives rise
to a natural notation for nullary functions:

(* 2 2 2)   ; evaluates to 8
(* 2 2)     ; evaluates to 4
(* 2)       ; evaluates to 2
(*)         ; evaluates to 1

and:

In mathematics and in computer programming, a variadic function is a
function of indefinite arity, i.e., one which accepts a variable
number of arguments. Support for variadic functions differs widely
among programming languages. 

I may alone assume, while still needing confirmation, that Emacs Lisp,
Common Lisp use those variadic function. Not that I have got stable
feeling with it.

Though that still does not tell me why? 

I have excluded the purpose for `apply' and similar functions as that
is handled properly with PicoLisp where (*) ➜ NIL -- and maybe I am
wrong, but with all references I came closer some reasoning. But all
the reasoning is not confirmed in Lisp books.

What I understand from C is thet if number of args nargs is 0 is that
result shall be 1 -- that alone does not explain why and how is it
useful in Lisp.

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);
}


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Ruijie Yu via Users list for the GNU Emacs text editor]

Hello Jean,

It seems to me that you still have some lingering questions regarding
this topic.  See below for my attempt to answer them.

Jean Louis <bugs@gnu.support> writes:

> * Nick Dokos <ndokos@gmail.com> [2023-01-17 19:27]:
>> The "empty sum" and "empty product" conventions are described in the
>> corresponding articles in Wikipedia too - they might help:
>>
>>    https://en.wikipedia.org/wiki/Empty_sum
>>    https://en.wikipedia.org/wiki/Empty_product
>
> Thanks much.
>
> I understand that "summation" is not equal to "addition" as summation
> is the addition of a sequence of any kind of numbers, called addends
> or summands; the result is their sum or total:
> https://en.wikipedia.org/wiki/Summation
>
> Then back to: https://en.wikipedia.org/wiki/Empty_sum
> where it says:
>
> In mathematics, an empty sum, or nullary sum,[1] is a summation where
> the number of terms is zero. The natural way to extend non-empty
> sums[2] is to let the empty sum be the additive identity.
>
> Basically function `+' deals with summation, not with addition. But
> that is conclusion I can draw alone with help of your references,
> without confirmation by docstring, manual or some references.
>
> Though I do not understand why it has to deal with summation, and not
> straight with addition? What is use in Lisp?

IIUC, are you asking why, within Emacs codebase, there is no 2-argument
"addition" function, in addition to the variadic summation function
known as `+'?  And similarly, why there is no 2-argument
"multiplication" function, in addition to the variadic product function
known as `*'?

IMO, the answer is threefold.  I believe most, if not all, of them have
been mentioned in previous messages of this thread, but hopefully by
listing them below side by side, it makes a bit more sense to you.

First, we can all agree that some sort of addition is needed, either
2-arg or variadic, in order to support the most basic functionalities
like motions within a buffer and making calculations.

Second, there should be plenty of cases (which I have not verified
within the codebase) where summing up a list of numbers is needed.  If
the variadic "summation" function is not available, then each such
library (first or third party) have to either implement their own
summation function, or use something like `(cl-reduce #'add-two-numbers
input-list :initial-value 0)'.

Third, if it is determined that a "summation" function is needed, then
the "addition" function is a strict subset of the summation function and
no longer necessary.  Suppose we have the two functions `add' (2-arg
only) and `sum' (variadic), I hope you can agree that these two
expressions are always equivalent in terms of their results:

    (add 1 2) ;=> 3
    (sum 1 2) ;=> 3

Because of the reasons above, IMO, the Emacs maintainers made a consious
decision that implementing the summation function as `+' is enough for
all its use cases, and it would be no longer necessary to have a
separate "addition" function.  Similarly, they decided to implement the
product function as `*'.

Admittedly, they could have implemented the following summation function
and have made `+' only accept 2 arguments, but not doing so is their
decision to make and do not introduce real functional differences:

    (defun sum (nums) (cl-reduce #'+ nums :initial-value 0))

The reason Emacs gets to make this decision (as opposed to, for example,
C) is because `+' and `*' are ordinary functions.  Consider C:
arithmetic expressions are made with an operator, a left-hand-side
expression and a right-hand-side expression.  There are no other
"sides".  Therefore, without introducing more complexity to the language
(e.g. special-casing a "sum" function which takes generic, variadic
arguments), it is only feasible for C to have 2-arg arithmetic
operators.

> In this other reference: https://en.wikipedia.org/wiki/Empty_product
> the issue with Lisp is mentioned, and we can read, that in many
> programming languages it is so, like in Python, Lisp, but in Perl is
> not so, then it says:
>
> Multiplication is an infix operator and therefore a binary operator,
> complicating the notation of an empty product. Some programming
> languages handle this by implementing variadic functions. For example,
> the fully parenthesized prefix notation of Lisp languages gives rise
> to a natural notation for nullary functions:
>
> (* 2 2 2)   ; evaluates to 8
> (* 2 2)     ; evaluates to 4
> (* 2)       ; evaluates to 2
> (*)         ; evaluates to 1
>
> and:
>
> In mathematics and in computer programming, a variadic function is a
> function of indefinite arity, i.e., one which accepts a variable
> number of arguments. Support for variadic functions differs widely
> among programming languages.
>
> I may alone assume, while still needing confirmation, that Emacs Lisp,
> Common Lisp use those variadic function. Not that I have got stable
> feeling with it.
>
> Though that still does not tell me why?
>
> I have excluded the purpose for `apply' and similar functions as that
> is handled properly with PicoLisp where (*) ➜ NIL -- and maybe I am
> wrong, but with all references I came closer some reasoning. But all
> the reasoning is not confirmed in Lisp books.

I don't have an answer for why other lisp dialects have different
defaults.

> What I understand from C is thet if number of args nargs is 0 is that
> result shall be 1 -- that alone does not explain why and how is it
> useful in Lisp.
>
> 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);
> }

Regarding why the default values of summation and product are 0 and 1
respectively, here is a concrete example use case (with analysis) where
said default values are needed:

    Consider you want to sum up *all values* inside a nested list to get
    a single value:

        (setq foo
              '((1 2 3 4) ;=> 10
                ()        ;=> 0
                (1))      ;=> 1

    To sum it manually, you see that this is essentially summing up the
    list '(1 2 3 4 1) to get 11.

    You can also write the following expression to calculate the sum:

        (apply #'+ (mapcar (lambda (lst) (apply #'+ lst)) foo))
        ;=> 11

    Notice how you have skipped the empty sublist.  In a sense, because
    this sublist is empty, you *don't add anything* to the accumulated
    result.  Mathematically, that is the same as adding 0.  Therefore,
    the only natural default value for summation is 0.

    This analysis can also be made for the default value of product,
    where when you skip an empty sublist, you *don't multiple anything*
    to the accumulated result, which is mathematically equivalent to
    multiplying by 1, which we can then conclude should be the natural
    default value for product.

Hope that helps.

Best,


RY

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

Thanks for effort. 

Maybe you missed my actual question. I strive to express me well. 

But then it become easy to deviate and go in other subjects, branching
to other justifications.

> > Basically function `+' deals with summation, not with addition.

I thank for your Explanations are not really what I asked

> IIUC, are you asking why, within Emacs codebase, there is no 2-argument
> "addition" function, in addition to the variadic summation function
> known as `+'?  And similarly, why there is no 2-argument
> "multiplication" function, in addition to the variadic product function
> known as `*'?

Thanks. Though I did not ask that. That is not my expression. But I
can rephrase it here, in this:

Checklist for fact finding:
---------------------------

- Is there any practical use for (*) ➜ 1 and (+) ➜ 0 alone?

- To show me the practical use example, I think that finding examples
  of Emacs Lisp could be useful:

  - where such Lisp would break if function like `*' would require 2
   arguments 

  - with tiny refactoring to make sure of the result
  
  - for example why multiply single number? Where is practical use?

- And maybe we could understand it from history of Lisp. But I could
  not find references.

> First, we can all agree that some sort of addition is needed, either
> 2-arg or variadic, in order to support the most basic functionalities
> like motions within a buffer and making calculations.

Thanks much for attempt, but that was not my question. 

> Second, there should be plenty of cases (which I have not verified
> within the codebase) where summing up a list of numbers is needed.  If
> the variadic "summation" function is not available, then each such
> library (first or third party) have to either implement their own
> summation function, or use something like `(cl-reduce #'add-two-numbers
> input-list :initial-value 0)'.

Here we are. If there are plenty of results, please find me one.

> Third, if it is determined that a "summation" function is needed, then
> the "addition" function is a strict subset of the summation function and
> no longer necessary.  Suppose we have the two functions `add' (2-arg
> only) and `sum' (variadic), I hope you can agree that these two
> expressions are always equivalent in terms of their results:
> 
>     (add 1 2) ;=> 3
>     (sum 1 2) ;=> 3
> 
> Because of the reasons above, IMO, the Emacs maintainers made a consious
> decision that implementing the summation function as `+' is enough for
> all its use cases, and it would be no longer necessary to have a
> separate "addition" function.  Similarly, they decided to implement the
> product function as `*'.

Thanks for your hypothetical explanation, though it does not show
usage of (*) ➜ 1 and none of Emacs developers told me that it is
so. Though what somebody was thinking could be maybe totally
irrelevant, as maybe the real reasons are in history of Lisp.

I am looking for facts, not for explanations in absence of facts.

Human mind tend to be perfect.

In absence of information, human mind tend to create information.

Newly created information is not necessarily the origin of information.

> > I have excluded the purpose for `apply' and similar functions as that
> > is handled properly with PicoLisp where (*) ➜ NIL -- and maybe I am
> > wrong, but with all references I came closer some reasoning. But all
> > the reasoning is not confirmed in Lisp books.
> 
> I don't have an answer for why other lisp dialects have different
> defaults.

You see?

While I am thankful for your good intention, the reasoning you brought
up is contradictory to the actual Picolisp example, as you do not have
answer to it.

> Regarding why the default values of summation and product are 0 and 1
> respectively, here is a concrete example use case (with analysis) where
> said default values are needed:
> 
>     Consider you want to sum up *all values* inside a nested list to get
>     a single value:
> 
>         (setq foo
>               '((1 2 3 4) ;=> 10
>                 ()        ;=> 0
>                 (1))      ;=> 1

Your `setq' above misses parenthesis:

        (setq foo
              '((1 2 3 4) 
                ()        
                (1))) ➜ ((1 2 3 4) nil (1))

>     To sum it manually, you see that this is essentially summing up the
>     list '(1 2 3 4 1) to get 11.

For me those are three lists, and I cannot know what author intended
to do with it. It is just variable assignment. I am inspecting it and
following your example.

>     You can also write the following expression to calculate the sum:
> 
>         (apply #'+ (mapcar (lambda (lst) (apply #'+ lst)) foo))
>         ;=> 11

(apply #'+ (mapcar (lambda (lst) (apply #'+ lst)) foo)) ➜ 11

Though I would never do it as you, as "empty" value I would never have
in the list. Why in the first place to bring yourself in position to
have empty value which you need to add? For me that is wrong programming.

>     Notice how you have skipped the empty sublist.  In a sense, because
>     this sublist is empty, you *don't add anything* to the accumulated
>     result.  Mathematically, that is the same as adding 0.  Therefore,
>     the only natural default value for summation is 0.

You are basically explaining me how the above s-expression hides the
real problem that programmer missed to provide number but provided NIL
instead. And the actual problem cannot be found because of it.

I would think different in that case:

(apply #'+ (flatten-list foo)) ➜ 11

But if I am really providig NIL values in a list, I would remove them,
so that at least for me remains readable, I must have some reason for
NIL values:

(let* ((foo '((1 2 3 4) () (1)))
       (foo (delq nil foo))
       (foo (flatten-list foo)))
  (apply #'+ foo)) ➜ 11

Of course in real life the `foo' would most probably get value from some function.

I am not impressed with the example.
     
>     This analysis can also be made for the default value of product,
>     where when you skip an empty sublist, you *don't multiple anything*
>     to the accumulated result, which is mathematically equivalent to
>     multiplying by 1, which we can then conclude should be the natural
>     default value for product.

Analysis did not answer to me "how it is useful". It has given
explanations which are beyond the practical use of functions like 
(*) ➜ 1

Let us say I want to multiply some elements of a list:

;; if I need to multiply elements, I do not need outside theory but
;; there is practical reason for multiplication. There shall be two
;; elements, if not, there is error:

(let ((list '(2 3)))
  (cond ((cadr list) (apply #'* list))p
	(t (user-error "Not enough arguments")))) ➜ 6

(let ((list '(2)))
  (cond ((cadr list) (apply #'* list))
	(t (user-error "Not enough arguments"))))

User error here, as why in first place did I send single argument?

Why in first place I wish to multiple something with nothing?

And then if I really need "2" as result, then I find it better to consciously return such result:

(let ((list '(2)))
  (cond ((cadr list) (apply #'* list))
	((car list) (car list))
	(t (user-error "Not arguments")))) ➜ 2

And what about those people who do not want to return the sole argument? 

(let* ((books-on-shelves (ignore 'myfunction nil))
       (shelves 2)
       (list (delq nil (list books-on-shelves shelves))))
  (cond ((cadr list) (apply #'* list))
	(t (user-error "Either shelves or books missing!"))))

If there is expectation of books on each shelf, then that is what I
wish to multiply. There is practical use visible in the function.

If I have expectation to know how many books are on shelves, I cannot
do this:

(let* ((books-on-shelves (ignore 'myfunction nil))
       (shelves 2)
       (list (delq nil (list books-on-shelves shelves))))
  (format "Number of total books: %d" (apply #'* list))) ➜ "Number of total books: 2"

But number of total books is not 2!

Because for reason that (*) ➜ 1 then I am getting wrong result!
---------------------------------------------------------------

I have shown you now practical example where (*) ➜ 1 is tricky as it
would give incorrect result and hide the real issue.

Do you have any example from me Checklist for fact finding how would
(*) ➜ 1 be practically useful?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Nick Dokos]

Nick Dokos <ndokos@gmail.com> writes:

> <tomas@tuxteam.de> writes:
>
>> On Mon, Jan 16, 2023 at 12:08:33AM +0300, Jean Louis wrote:
>>> * Rudolf Adamkovič <salutis@me.com> [2023-01-15 23:27]:
>>> > Jean Louis <bugs@gnu.support> writes:
>>> > 
>>> > >> (+) ➜ 0
>>> > >
>>> > > Why? It is wrong.
>>> > 
>>> > In Lisp, the `+' operator returns the sum of the additive identity with all of
>>> > its arguments.  The additive identity equals zero and you provided zero
>>> > arguments.  Hence, you get the additive identity.
>>> 
>>> Send me references on what is additive identity.
>>
>> Identity element [0] as defined in group theory [1].
>>
>> The association of 0 with + and 1 with * runs deeper in maths
>> than you think.
>>
>>> Though that it is so, it does not answer why is it so.
>>
>> Those are, of course, conventions. As whether the natural
>> numbers begin with 0 or 1. But the above is, AFAIK, most
>> widespread among mathematicians, wheter the latter is not.
>>
>> Cheers
>>
>> [0] https://en.wikipedia.org/wiki/Identity_element
>> [1] https://en.wikipedia.org/wiki/Group_theory
>
> The "empty sum" and "empty product" conventions are described in the
> corresponding articles in Wikipedia too - they might help:
>
>    https://en.wikipedia.org/wiki/Empty_sum
>    https://en.wikipedia.org/wiki/Empty_product

Ugh - misposted to the wrong thread. Sorry about that. No idea how I managed that.

-- 
Nick

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Yuri Khan]

On Mon, 16 Jan 2023 at 11:44, Jean Louis <bugs@gnu.support> wrote:

> > >> (+) ➜ 0
> > >
> Send me references on what is additive identity.
>
> Though that it is so, it does not answer why is it so.

Consider a sum of n elements: S = (+ x_1 … x_{n-1} x_n).
By definition, it is equal to the sum of the first n-1 elements, plus
the nth element: S = (+ x_1 … x_{n-1}) + x_n. No problem this far?
(except for me mixing prefix and infix notation)

Now, plug n=1 into this general formula.
S = x_1 = (+) + x_1.
Therefore, the sum of an empty list (+) has to be 0.

In the same vein, a product of n elements: P = (* x_1 … x_{n-1} x_n) =
(* x_1 … x_{n-1}) * x_n, which in the case of n=1 becomes P = x_1 =
(*) * x_1. Therefore, the product of the empty list (*) has to be 1.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2023-01-16 10:57]:
> On Mon, 16 Jan 2023 at 11:44, Jean Louis <bugs@gnu.support> wrote:
> 
> > > >> (+) ➜ 0
> > > >
> > Send me references on what is additive identity.
> >
> > Though that it is so, it does not answer why is it so.
> 
> Consider a sum of n elements: S = (+ x_1 … x_{n-1} x_n).
> By definition, it is equal to the sum of the first n-1 elements, plus
> the nth element: S = (+ x_1 … x_{n-1}) + x_n. No problem this far?
> (except for me mixing prefix and infix notation)
> 
> Now, plug n=1 into this general formula.
> S = x_1 = (+) + x_1.
> Therefore, the sum of an empty list (+) has to be 0.

By above I do not see reference to Lisp. What you state above is not
what Lisp function is supposed to do and it does not tell why is it
so in Lisp, do you know?

I understand "identity element" but I do not see relation between
group theory and arithmetic function in Lisp context `+':

> + is a built-in function in ‘C source code’.
> (+ &rest NUMBERS-OR-MARKERS)
> Return sum of any number of arguments, which are numbers or markers.

It does not say "Return sum of any number of arguments, which are
numbers or markers, or if no arguments return identity element by
using group theory, blah..."

I actually expect function to tell me wrong number of arguments or no
arguments, as I find it safer for programming that way.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Yuri Khan]

On Mon, 16 Jan 2023 at 17:17, Jean Louis <bugs@gnu.support> wrote:

> By above I do not see reference to Lisp. What you state above is not
> what Lisp function is supposed to do and it does not tell why is it
> so in Lisp, do you know?

In mathematics the sum of zero elements is zero and the product of
zero elements is one. In Lisp the + function implements the
mathematical sum, and * the product. Lisp chooses to allow more than
two arguments for the sum and product, so why would it impose any
artificial restriction on less than one?

> > + is a built-in function in ‘C source code’.
> > (+ &rest NUMBERS-OR-MARKERS)
> > Return sum of any number of arguments, which are numbers or markers.

What it doesn’t say explicitly is that any markers are implicitly
converted to numbers. After that, all arguments (if any) are numbers,
and can be dealt with according to number rules.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2023-01-16 13:39]:
> On Mon, 16 Jan 2023 at 17:17, Jean Louis <bugs@gnu.support> wrote:
> 
> > By above I do not see reference to Lisp. What you state above is not
> > what Lisp function is supposed to do and it does not tell why is it
> > so in Lisp, do you know?
> 
> In mathematics the sum of zero elements is zero and the product of
> zero elements is one. 

There are no elements in this context. 

(+) ➜ 0

Multiplication of zero elements is also zero:
(* 0 0) ➜ 0
but Lisp:
(*) ➜ 1

It is not sufficiently logic. You can put X theories, but make it
consistent. 

> In Lisp the + function implements the mathematical sum, and * the
> product. Lisp chooses to allow more than two arguments for the sum
> and product, so why would it impose any artificial restriction on
> less than one?

You may find it entertaining, but I did not get answer that way.

> > > + is a built-in function in ‘C source code’.
> > > (+ &rest NUMBERS-OR-MARKERS)
> > > Return sum of any number of arguments, which are numbers or markers.
> 
> What it doesn’t say explicitly is that any markers are implicitly
> converted to numbers. After that, all arguments (if any) are numbers,
> and can be dealt with according to number rules.

Buffer location markers? How do I add markers to each other?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Yuri Khan]

On Mon, 16 Jan 2023 at 22:50, Jean Louis <bugs@gnu.support> wrote:

> There are no elements in this context.
>
> (+) ➜ 0

There is a list of elements, and the length of that list is zero.

> Multiplication of zero elements is also zero:
> (* 0 0) ➜ 0
> but Lisp:
> (*) ➜ 1

You are conflating elements of zero value with a zero count of elements.

You are not willing to understand. I suspect you also will not believe
me if I tell you all my dogs have green hair.

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2023-01-16 19:01]:
> On Mon, 16 Jan 2023 at 22:50, Jean Louis <bugs@gnu.support> wrote:
> 
> > There are no elements in this context.
> >
> > (+) ➜ 0
> 
> There is a list of elements, and the length of that list is zero.
> 
> > Multiplication of zero elements is also zero:
> > (* 0 0) ➜ 0
> > but Lisp:
> > (*) ➜ 1
> 
> You are conflating elements of zero value with a zero count of elements.
> 
> You are not willing to understand. I suspect you also will not believe
> me if I tell you all my dogs have green hair.

I am very willing to understand. This should not be place of laughing
me out because I keep asking questions.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Mon, Jan 16, 2023 at 07:14:49PM +0300, Jean Louis wrote:
> * Yuri Khan <yuri.v.khan@gmail.com> [2023-01-16 19:01]:
> > On Mon, 16 Jan 2023 at 22:50, Jean Louis <bugs@gnu.support> wrote:
> > 
> > > There are no elements in this context.
> > >
> > > (+) ➜ 0
> > 
> > There is a list of elements, and the length of that list is zero.
> > 
> > > Multiplication of zero elements is also zero:
> > > (* 0 0) ➜ 0
> > > but Lisp:
> > > (*) ➜ 1
> > 
> > You are conflating elements of zero value with a zero count of elements.
> > 
> > You are not willing to understand. I suspect you also will not believe
> > me if I tell you all my dogs have green hair.
> 
> I am very willing to understand. This should not be place of laughing
> me out because I keep asking questions.

Again: the behaviour of Lisp's + and * is modeled after maths
conventions. Assuming you've read both Wikipedia references I
linked to you might understand why those conventions "make sense"
(no they are not theorems or some such, just conventions, you
notice that proofs and formulae are usually simpler).

The mathematical things modeled by Lisp's + and * are the
summation Σ and the product Π. In maths, the empty sum
evaluates to 0, the empty product to 1 [1] [2] (for the
last one: otherwise this would be at odds that a number
raised to the zeroth power also yields 1).

So why would Lisp, modeling numbers (roughly) after maths,
deviate from math conventions?

If you do functional programming, this corresponds nicely
to anamorphisms [3]: you have a start value and a two-place
funtion and calculate the next "start" value by combininb
the old one with the next in the list.

For sums, your start value would be zero. For products?
Nah :)

Cheers

[1] "If the summation has no summands, then the evaluated sum is
     zero, because zero is the identity for addition. This is
     known as the empty sum."
    https://en.wikipedia.org/wiki/Sigma_notation#Special_cases

[2] "[...] an empty product whose value is 1 -- regardless of the
     expression for the factors."
    https://en.wikipedia.org/wiki/Capital-pi_notation#Capital_pi_notation

[3] Google called them "reduce" in their "map-reduce" framework,
    but they try to put their scent on everything. They didn't
    invent them. Oh, that's the way you can define aggregates
    in your beloved PostgreSQL, too.
    https://en.wikipedia.org/wiki/Anamorphism
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Drew Adams]

> > You are not willing to understand. I suspect you also will not believe
> > me if I tell you all my dogs have green hair.
> 
> I am very willing to understand. This should not be place of laughing
> me out because I keep asking questions.

Agreed 100%.  I think you are genuinely trying
to understand, and that's behind your questions.

I think the replies you've gotten already might
well help you understand.  Please consider
rereading them.

Sometimes it takes a little extra pondering,
then suddenly a light bulb goes on, just by
seeing something a little differently.

(I remember that happening to me in a Physics
class when the concept of a "field" finally
grabbed hold of me.)

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-01-16 20:07]:
> I think the replies you've gotten already might well help you
> understand.  Please consider rereading them.

I do not dispute that group theory exists, or identity, and it is part
of mathematic.

I do not see relation between identity and lisp function which is
supposed to give product of multiplication or sum of addition, and I
can't imagine that Lisp authors did that to those functions for reasons
to avoid `apply' function to fail.

There are X number of mathematical stuff that is not represented in
Lisp because it should not be there, a function should do one thing well.

What is missing in my understanding is:

- purpose of (*) ➜ 1, (-) ➜ 0 and (+) ➜ 0 as I do not understand how I
  would apply it else but making a funny Christmass tree in obscured
  programming and relation to Lisp. I have tried searching for
  references but can't find.

(defun m (n)
  (let ((m))
  (dotimes (b n)
    (setq m (cons "(*)" m)))
  (concat "(+" (string-join m) ")")))

(let ((first 1))
  (insert "\n")
  (while (<= first 10)
    (let ((second 1))
      (while (<= second 10)
	(insert "(*" (m first)(m second) ")\n")
	(setq second (1+ second)))
      (setq first (1+ first)))))

One reference to it I find in "Common Lisp - A Gentle Introduction to
Symbolic Computing":

> Suppose x and y are lists. (REDUCE #’+ (APPEND x y)) should produce
> the same value as the sum of (REDUCE #’+ x) and (REDUCE #’+ y). If y
> is NIL, then (APPEND x y) equals x, so (REDUCE #’+ y) has to return
> zero. Zero is the identity value for addition. That’s why calling +
> with no arguments returns zero. Similarly, calling * with no arguments
> returns one because one is the multiplicative identity.

Let's compare:

(let ((x '(3 3 3))
      (y '(4 4 4)))
  (reduce #'* (append x y))) ➜ 1728
Same in Common Lisp

(let ((x '(3 3 3))
      (y '(4 4 4)))
  (+ (reduce #'+ x) (reduce #'+ y))) ➜ 21
Same in Common Lisp

Am I wrong here making sum how it said I should make?

(let ((x '(3 3 3))
      (y nil))
  (append x y)) ➜ (3 3 3)
I cannot see that (append x y) equals x -- I cannot follow the example

(let ((x '(3 3 3))
      (y nil))
  (reduce #'+ y)) ➜ 0
This is correct as in example

Again I read "That's why calling + with no arguments returns zero" and do they mean that "why" is with reason to make function `reduce' work similarly like to make `apply' work?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Anders Munch]

Jean Louis wrote:
> I actually expect function to tell me wrong number of arguments or no arguments, as I find it safer for programming that way.

It makes sense for 
	 (+)
to be an error, if it's written like that.
But if the code goes
	(apply #'+ a-list-of-numbers)
then a-list-of-numbers being empty is normal and expected, and 0 is invariably the desired result.
You can't make the former an error without the latter becoming an error as well, so it isn't.

regards,
Anders

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Anders Munch <ajm@flonidan.dk> [2023-01-16 13:58]:
> Jean Louis wrote:
> > I actually expect function to tell me wrong number of arguments or no arguments, as I find it safer for programming that way.
> 
> It makes sense for 
> 	 (+)
> to be an error, if it's written like that.
> But if the code goes
> 	(apply #'+ a-list-of-numbers)
> then a-list-of-numbers being empty is normal and expected, and 0 is invariably the desired result.
> You can't make the former an error without the latter becoming an error as well, so it isn't.

(apply #'+ nil) that is what you mean why is it usable?

than this is disaster:

(apply #'* nil) ➜ 1

Do you wish to say that `apply' function is reason for this below?

(*) ➜ 1 and 
(+) ➜ 0 and
(-) ➜ 0

Maybe you know some reference to Lisp beginning why is it so?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Andreas Eder]

On Mo 16 Jan 2023 at 18:38, Jean Louis <bugs@gnu.support> wrote:

> * Anders Munch <ajm@flonidan.dk> [2023-01-16 13:58]:
>> Jean Louis wrote:
>> > I actually expect function to tell me wrong number of arguments or no arguments, as I find it safer for programming that way.
>> 
>> It makes sense for 
>> 	 (+)
>> to be an error, if it's written like that.
>> But if the code goes
>> 	(apply #'+ a-list-of-numbers)
>> then a-list-of-numbers being empty is normal and expected, and 0 is invariably the desired result.
>> You can't make the former an error without the latter becoming an error as well, so it isn't.
>
> (apply #'+ nil) that is what you mean why is it usable?
>
> than this is disaster:
>
> (apply #'* nil) ➜ 1
>
> Do you wish to say that `apply' function is reason for this below?
>
> (*) ➜ 1 and 
> (+) ➜ 0 and
> (-) ➜ 0
>
> Maybe you know some reference to Lisp beginning why is it so?

See http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.htm for
#'+ and http://www.lispworks.com/documentation/HyperSpec/Body/f_st.htm
for #'*.

'Andreas

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Mon, Jan 16, 2023 at 06:40:07PM +0100, Andreas Eder wrote:
> On Mo 16 Jan 2023 at 18:38, Jean Louis <bugs@gnu.support> wrote:

[...]

> > Do you wish to say that `apply' function is reason for this below?
> >
> > (*) ➜ 1 and 
> > (+) ➜ 0 and
> > (-) ➜ 0
> >
> > Maybe you know some reference to Lisp beginning why is it so?
> 
> See http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.htm for
> #'+ and http://www.lispworks.com/documentation/HyperSpec/Body/f_st.htm
> for #'*.

And -- oh, to make things more interesting:

(and) => t
(or) => f

It's a conspiracy ;-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2023-01-16 21:20]:
> And -- oh, to make things more interesting:
> 
> (and) => t
> (or) => f
> 
> It's a conspiracy ;-)

Similar though not same:

and is a special form in ‘C source code’.

(and CONDITIONS...)

Eval args until one of them yields nil, then return nil.
The remaining args are not evalled at all.
If no arg yields nil, return the last arg’s value.

There is no description that it should return true without arguments.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Mon, Jan 16, 2023 at 09:55:47PM +0300, Jean Louis wrote:
> * tomas@tuxteam.de <tomas@tuxteam.de> [2023-01-16 21:20]:
> > And -- oh, to make things more interesting:
> > 
> > (and) => t
> > (or) => f
> > 
> > It's a conspiracy ;-)
> 
> Similar though not same:

The underlying mathematical structures are:

  - numbers (I'm handwaving a bit here) with + form a monoid,
    the neutral element is 0
  - numbers with * form a monoid, the neutral element is 1
    (if you need a group, you'll have to exclude 0, though)
  - booleans with and form a monoid, the neutral is t
  - booleans with or form a monoid, the neutral is nil

Next: function composition: what is the neutral there?

(this is what maths is good at)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Jean Louis]

* Andreas Eder <a_eder_muc@web.de> [2023-01-16 20:42]:
> > Maybe you know some reference to Lisp beginning why is it so?
> 
> See http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.htm for
> #'+ and http://www.lispworks.com/documentation/HyperSpec/Body/f_st.htm
> for #'*.

Thanks. 

"Returns the product of numbers, performing any necessary type
conversions in the process. If no numbers are supplied, 1 is
returned."

I understand 1 is returned, yet I am still searching for purpose.

For now vague purpose is only to satisfy some other functions which
process lists, like `reduce' or `apply', I am searching for
confirmation if that was the sole purpose.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?

[Eduardo Ochs]

On Mon, 16 Jan 2023 at 15:56, Jean Louis <bugs@gnu.support> wrote:
>
> * Andreas Eder <a_eder_muc@web.de> [2023-01-16 20:42]:
> > > Maybe you know some reference to Lisp beginning why is it so?
> >
> > See http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.htm for
> > #'+ and http://www.lispworks.com/documentation/HyperSpec/Body/f_st.htm
> > for #'*.
>
> Thanks.
>
> "Returns the product of numbers, performing any necessary type
> conversions in the process. If no numbers are supplied, 1 is
> returned."
>
> I understand 1 is returned, yet I am still searching for purpose.
>
> For now vague purpose is only to satisfy some other functions which
> process lists, like `reduce' or `apply', I am searching for
> confirmation if that was the sole purpose.

Hi Jean,

a few months ago I had to prepare some figures to explain to my
students what should be the "neutral elements" for some operations...
The main idea is that we want all these expressions to yield the same
result, including the two last ones, that are weird,

  (+ (+ 2 2) (+ 2 2 2 2 2))
  (+ (+ 2 2 2) (+ 2 2 2 2))
  (+ (+ 2 2 2 2) (+ 2 2 2))
  (+ (+ 2 2 2 2 2) (+ 2 2))
  (+ (+ 2 2 2 2 2 2) (+ 2))
  (+ (+ 2 2 2 2 2 2 2) (+))

and the same thing for these expressions:

  (* (* 2 2) (* 2 2 2 2 2))
  (* (* 2 2 2) (* 2 2 2 2))
  (* (* 2 2 2 2) (* 2 2 2))
  (* (* 2 2 2 2 2) (* 2 2))
  (* (* 2 2 2 2 2 2) (* 2))
  (* (* 2 2 2 2 2 2 2) (*))

My figures are in the pages 86 and 87 of this PDF,

  http://angg.twu.net/LATEX/2022-2-C2-tudo.pdf#page=86

and my real objective was to convince them that we had very good
reasons to decide that the result of (or) should be false the result
of (and) should be true, and then extend these ideas to "for all" and
"exists".

  Cheers,
    Eduardo

(*) -> 1

[Jean Louis]

* Eduardo Ochs <eduardoochs@gmail.com> [2023-01-17 05:39]:
> a few months ago I had to prepare some figures to explain to my
> students what should be the "neutral elements" for some operations...
> The main idea is that we want all these expressions to yield the same
> result, including the two last ones, that are weird,
> 
>   (+ (+ 2 2) (+ 2 2 2 2 2))
>   (+ (+ 2 2 2) (+ 2 2 2 2))
>   (+ (+ 2 2 2 2) (+ 2 2 2))
>   (+ (+ 2 2 2 2 2) (+ 2 2))
>   (+ (+ 2 2 2 2 2 2) (+ 2))
>   (+ (+ 2 2 2 2 2 2 2) (+))

That still does not make sense to me. I translate that to ordinary
notation:

 (2 + 2) + (2 + 2 + 2 + 2 + 2)
 (2 + 2 + 2) + (2 + 2 + 2 + 2)
 (2 + 2 + 2 + 2) + (2 + 2 + 2)
 (2 + 2 + 2 + 2 + 2) + (2 + 2)
 (2 + 2 + 2 + 2 + 2 + 2) + 2
 (2 + 2 + 2 + 2 + 2 + 2 + 2) + -- this is impossible situation as
 summand is missing because 
 "14 + " lacks summand. There must be some number first. 

People speak how Lisp follows mathematical conventions, but obviously
it follows some, but not all. 

Convention in multiplication is that there must be two numbers, that
is not followed, something else is followed. The reason behind is what?

> and my real objective was to convince them that we had very good
> reasons to decide that the result of (or) should be false the result
> of (and) should be true, and then extend these ideas to "for all" and
> "exists".

I wish I could see that good reason. 

Just by placing (+) and expecting it to yield something is not clear
that it is good reason.

I expect it then also here, but it does not work:

(/ (/ 2 2) (/))

So the above alone can't explain my why is it that Lisp uses
identities.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Convention in multiplication is that there must be two numbers, that
> is not followed, something else is followed.

There is no such convention.

> I expect it then also here, but it does not work:
>
> (/ (/ 2 2) (/))

You don't listen to or don't understand what people write.  Could you
please try to do that before continuing this discussion?  It doesn't
seem to be the case that you are consulting the references that had been
presented to you.  So why are you keeping asking?

Sorry to be direct like this, but what you are doing had been quite
unfriendly for a while now.

Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 18:58]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Convention in multiplication is that there must be two numbers, that
> > is not followed, something else is followed.
> 
> There is no such convention.

Every elementary school is there to prove that convention of having at
least two addends for addition and two factors for multiplication
exists.

Thus, sorry, you reality does not correspond to mine.

There is no elementary school and I know many of them where pupils
would learn how in absence of any factor one shall count 1.

By chance, I am providing roomt to mathematics teacher who was not
introduced to this discussion, and I just called him and asked him if
there is anything that he knows that in absence of factors, the
multiplication operation would yield with anything, and he has no idea
what we are talking about.

What idea he has is that there must be 2 known factors for
multiplications and similar for addition.

That there may be some convention is not excluded, and that there is
identity element in mathematics is fine, but even the page of identity
element does not speak of creation of identity elements, but of usage
of identity elements.

Then we have contradiction that description of functions `*' and `+'
and `-' does not speak of any sets or group theory. And we have people
speaking yes, group theory, sets. 

But not description of relation from sets to Lisp function, why?

> You don't listen to or don't understand what people write.  Could
> you please try to do that before continuing this discussion?  It
> doesn't seem to be the case that you are consulting the references
> that had been presented to you.  So why are you keeping asking?

> Sorry to be direct like this, but what you are doing had been quite
> unfriendly for a while now.

I am sorry for your feelings. Solution is simple, just do M-x doctor


I have not find a reference. And I do not ask if identity element
exists, neither if sets exists, etc.

I am asking why is it in (some) Lisps? It is so far contradictory to
explanation of what function is supposed to do.

I can really understand and imagine, vividly, how you get angered by
Jean Louis, who keep asking same question over again. No, I did not
understand it. I have tried search engines. Where else shall I ask?

Picolisp does not think same:

(apply '+ '(1 2 3))
-> 6

and

(+)
-> NIL

while in Emacs Lisp

(apply '+ '(1 2 3)) ➜ 6
(+) ➜ 0

That makes vague the answer to "why" that one has to use it in such
functions as `apply', as Picolisp obviously does not do that way.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Tue, Jan 17, 2023 at 07:29:32PM +0300, Jean Louis wrote:
> * Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 18:58]:
> > Jean Louis <bugs@gnu.support> writes:
> > 
> > > Convention in multiplication is that there must be two numbers, that
> > > is not followed, something else is followed.
> > 
> > There is no such convention.
> 
> Every elementary school is there to prove that convention of having at
> least two addends for addition and two factors for multiplication
> exists.

You shouldn't generalise what "every elementary school..." does. You
wouldn't have Bessel functions then.

Higher maths are a superset of (and sometimes a correction of) what
is taught in elementary schools. Lisp takes this inspiration from
higher maths. John McCarthy [1] was a mathematician by training and
most definitely had no qualms with zero- or one-term products and
sums. You have no choice but (believe me, I studied that too). As
soon as you have general sum and product formulae, you /need/ to
define what happens in border cases, and those conventions you seem
to dislike so much have turned out to be the most convenient,
probably since the mid-19th century.

But I think we've wrangled enough with this. At least me. If you don't
want to accept that others (including mathematicians) prefer other
conventions than you do... please, keep your bubble. I'll keep mine :)

I'm out of this.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: (*) -> 1

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2023-01-17 19:45]:
> Higher maths are a superset of (and sometimes a correction of) what
> is taught in elementary schools. Lisp takes this inspiration from
> higher maths. John McCarthy [1] was a mathematician by training and
> most definitely had no qualms with zero- or one-term products and
> sums. You have no choice but (believe me, I studied that too). As
> soon as you have general sum and product formulae, you /need/ to
> define what happens in border cases, and those conventions you seem
> to dislike so much have turned out to be the most convenient,
> probably since the mid-19th century.

Thanks. I am following your hints, but I am not getting answer.

If you know why they are convenient, can you please explain me? That
is what I am asking.

By following your guidance, I have found McCarthy Lisp:

appleby/mccarthy-lisp: A toy lisp inspired by McCarthy's paper:
https://github.com/appleby/mccarthy-lisp

and I did not verify if that Lisp follows really McCarthy, but I git
pull-ed it and compiled, and did not find reference in McCarthy's
Lisp, because McCarthy says:

mclisp> (*)
Read Error: Expected start of Cons or Symbol, found: *


~/Programming/git/mccarthy-lisp
$ make
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/main.cc -c -o src/main.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/alloc.cc -c -o src/alloc.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/cons.cc -c -o src/cons.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/env.cc -c -o src/env.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/error.cc -c -o src/error.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/eval.cc -c -o src/eval.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/init.cc -c -o src/init.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/lexer.cc -c -o src/lexer.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/load.cc -c -o src/load.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/reader.cc -c -o src/reader.o
clang++ -I ./src -g -O3 -Wall -Wextra -std=c++11 src/utils.cc -c -o src/utils.o
clang++ src/main.o src/alloc.o src/cons.o src/env.o src/error.o src/eval.o src/init.o src/lexer.o src/load.o src/reader.o src/utils.o -o mclisp
~/Programming/git/mccarthy-lisp
$ ls
difftests.lisp	LICENSE  Makefile  mclisp*  mclisp.lisp  README.md  src/  test/  test.lisp  TODO
~/Programming/git/mccarthy-lisp
$ ./mclisp
Loading mclisp.lisp... done.
mclisp> (*)
Read Error: Expected start of Cons or Symbol, found: *
mclisp> (-)
Read Error: Expected start of Cons or Symbol, found: -
mclisp> (+)
Read Error: Expected start of Cons or Symbol, found: +
mclisp> 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Nick Dokos]

Jean Louis <bugs@gnu.support> writes:

> * tomas@tuxteam.de <tomas@tuxteam.de> [2023-01-17 19:45]:
>> Higher maths are a superset of (and sometimes a correction of) what
>> is taught in elementary schools. Lisp takes this inspiration from
>> higher maths. John McCarthy [1] was a mathematician by training and
>> most definitely had no qualms with zero- or one-term products and
>> sums. You have no choice but (believe me, I studied that too). As
>> soon as you have general sum and product formulae, you /need/ to
>> define what happens in border cases, and those conventions you seem
>> to dislike so much have turned out to be the most convenient,
>> probably since the mid-19th century.
>
> Thanks. I am following your hints, but I am not getting answer.
>
> If you know why they are convenient, can you please explain me? That
> is what I am asking.

[ I posted some references that might help, but I posted them in the
wrong thread :( ]

The "empty sum" and "empty product" conventions are described in the
corresponding articles in Wikipedia too - they might help:

   https://en.wikipedia.org/wiki/Empty_sum
   https://en.wikipedia.org/wiki/Empty_product

Do not think of `(+ ...)' in Lisp as the (binary)
addition operator: think of it as the sum operator (denoted Σ in math)
which adds up a whole sequence of numbers. Similarly, think of `(*
...)' in Lisp as the product operator (denoted Π in math). It is more
pre-calculus level math, rather than elementary school math.

The conventions are useful in math because they simplify proofs, by
eliminating special cases. The same conventions are useful in Lisp,
because they make the Lisp operators behave similarly to the math
operators, so everything that you know about them can translate
directly to Lisp.

That's the *whole* point: there is nothing more to it.

-- 
Nick

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Every elementary school is there to prove that convention of having at
> least two addends for addition and two factors for multiplication
> exists.

Ok...

My neighbor has one garage with 2 Ferraris.  Altogether he has (+ 2) ==>
2 Ferraris.  Not an undefined number of Ferraris.  So you see that
extending the sum operator to one summand is natural and makes sense.

I OTOH have no garage.  The number of my Ferraris in all my garages is
(+) -> 0 Ferraries.  The count of my Ferraris in all of my garages is
actually defined, as the number of my garages is.  It is really 0, not
undefined.  I can't write to the tax office that the number of Ferraris
in my garages is undefined because there are zero summands and thus I
can't calculate the number.

> By chance, I am providing roomt to mathematics teacher who was not
> introduced to this discussion, and I just called him and asked him if
> there is anything that he knows that in absence of factors, the
> multiplication operation would yield with anything, and he has no idea
> what we are talking about.

This convention is not so useful in elementary school, at least not
literally.  And unfortunately, at least here in Germany, a lot of
mathematics teachers don't understand math very well.

But you might have learned that multiplication is repeated summation (I
think I already gave this example a couple of times but never got a
response):


  2*9 = 9 + 9 (two summands)
  1*9 = 9     (one summand)
  0*9 = ???   (it's 0 at least)

When it's allowed for `*' to handle cases that could be interpreted (!)
as the sum of zero arguments, why should a _generalization_ of `+' not
be allowed to?  Note that adding things like Ferraris is only an
_interpretation_ of a formula.  A product with zero factors might not
have a useful direct interpretation in the real world, but complex
numbers also don't have, and that doesn't mean that it can't be useful
to extend the formalisms that once were _inspired_ by things in the real
world.  What sum corresponds pi^2 to?

So what you fail to see is that not everything in maths can be directly
demonstrated using apples and pears.  But that doesn't mean that it's
not worth to include these parts of maths in programming languages.

If you are really doing maths, or are really working with sums in
programming, you'll see why and where these convention make sense.  And
in programming, it's a bit like with everything new you learn: you don't
miss it before you get to know it.

> What idea he has is that there must be 2 known factors for
> multiplications and similar for addition.

That doesn't mean that it can't be _extended_.  Like the natural numbers
can be extended to the whole numbers etc.  It's generalization and
abstraction.  You don't learn all of that in elementary school.

> That there may be some convention is not excluded, and that there is
> identity element in mathematics is fine, but even the page of identity
> element does not speak of creation of identity elements, but of usage
> of identity elements.

It's just not important enough, it's a little detail.  Like in Elisp.
It might sound super important and big to you right now but we are
speaking about a tiny corner case all the time.  We don't mention that
(* 0 n) returns 0 in the docstring of `*', for example.

> Then we have contradiction that description of functions `*' and `+'
> and `-' does not speak of any sets or group theory. And we have people
> speaking yes, group theory, sets. 
>
> But not description of relation from sets to Lisp function, why?

We have argument _lists_ that play the role of sets.

> I am asking why is it in (some) Lisps?

Because it's more convenient than raising an error.  Examples had been
outlined in this thread.


Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 20:20]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Every elementary school is there to prove that convention of having at
> > least two addends for addition and two factors for multiplication
> > exists.
> 
> Ok...
> 
> My neighbor has one garage with 2 Ferraris.  Altogether he has (+ 2) ==>
> 2 Ferraris.  Not an undefined number of Ferraris.  So you see that
> extending the sum operator to one summand is natural and makes sense.
> 
> I OTOH have no garage.  The number of my Ferraris in all my garages is
> (+) -> 0 Ferraries.

Don't add Ferraris, just multiply them and you will get one.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> > I OTOH have no garage.  The number of my Ferraris in all my garages is
> > (+) -> 0 Ferraries.
>
> Don't add Ferraris, just multiply them and you will get one.

Note that when (+ 2 3) would yield 7 in Elisp, I would accept your "it's
wrong" because there is a valid interpretation using Ferraris: (+ 2 3)
should return the number of Ferraris of two sets of two and three
Ferraris, and these are five Ferraris.

But what calculation involving Ferraris would (*) correspond to?  I
don't see any interpretation of the formula that would apply to
Ferraris, so it's not valid to say that a result of "one Ferrari" is
wrong.  What should that have calculated?

Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 21:48]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > > I OTOH have no garage.  The number of my Ferraris in all my garages is
> > > (+) -> 0 Ferraries.
> >
> > Don't add Ferraris, just multiply them and you will get one.
> 
> Note that when (+ 2 3) would yield 7 in Elisp, I would accept your "it's
> wrong" because there is a valid interpretation using Ferraris: (+ 2 3)
> should return the number of Ferraris of two sets of two and three
> Ferraris, and these are five Ferraris.

> But what calculation involving Ferraris would (*) correspond to?  I
> don't see any interpretation of the formula that would apply to
> Ferraris, so it's not valid to say that a result of "one Ferrari" is
> wrong.  What should that have calculated?

In absence of factors it should give error. That is my expectation.

And not in absence of factors to give whole series of Ferraris:

(+ (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)) ➜ 16

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 20:20]:
> But you might have learned that multiplication is repeated summation (I
> think I already gave this example a couple of times but never got a
> response):
> 
> 
>   2*9 = 9 + 9 (two summands)
>   1*9 = 9     (one summand)
>   0*9 = ???   (it's 0 at least)

and how do you use represent that in Emacs Lisp? Though we actually
speak of following

    * = 1

because it is absence of summands. Not presence.

> When it's allowed for `*' to handle cases that could be interpreted (!)
> as the sum of zero arguments, why should a _generalization_ of `+' not
> be allowed to?

Above sounds as capricious decision. I assume that Lisp makers who
decided that (*) ➜ 1 did not have capricious decision, but they had
something else in mind, something we did not yet mention here, and
that something is what I am searching.

> Note that adding things like Ferraris is only an _interpretation_ of
> a formula.  A product with zero factors might not have a useful
> direct interpretation in the real world, but complex numbers also
> don't have, and that doesn't mean that it can't be useful to extend
> the formalisms that once were _inspired_ by things in the real
> world.  What sum corresponds pi^2 to?

I don't really search for useful interpretation in real world, just in
Emacs Lisp or similar, why is it useful in Lisp?

Do you have mathematical exercise in Lisp that may demonstrate it
usefulness?

Is it only for representation purposes like Eduardo explained,
something like:

(* 2 2 2) ➜ 8
(* 2 2) ➜ 4
(* 2) ➜ 2
(*) ➜ 1

Do you think it is only for representation or consistency purposes? Or
there is some actual use?

> So what you fail to see is that not everything in maths can be
> directly demonstrated using apples and pears.

I don't fail to see that, because I know that 2 plus 2 is never 4,
that is just absolute representation, and in reality (almost) not
possible, as things like apples or Ferraris, chips, they are never
same, we have to imagine that one thing is same to other for
mathematics to work, as there is useful application of it. So no, that
is not problem.

What I do not see is why is it convenient in Lisp.

> But that doesn't mean that it's not worth to include these parts of
> maths in programming languages.

OK I understand people in Common Lisp included it, and Emacs Lisp has
it, and other Lisps. But why for example Emacs Lisp has (-) ➜ 0 but
other Lisps not?

Maybe in Emacs Lisp authors found some use for it?

Or do they include it just because? Just because set theory, blah
blah, so let us include it, but we see no reason for it. This is not
believable. I believe there is some practical reason behind it.

Reason that was not yet shown, but I feel it may be shown by somebody.

> If you are really doing maths, or are really working with sums in
> programming, you'll see why and where these convention make sense. 

I have no doubt for it. But show me use in Lisp as I do not ask about
outside theories, but why is it included in Lisp. Is there
example?

> And in programming, it's a bit like with everything new you learn:
> you don't miss it before you get to know it.

It still remains mystery.

> > What idea he has is that there must be 2 known factors for
> > multiplications and similar for addition.
> 
> That doesn't mean that it can't be _extended_.  Like the natural numbers
> can be extended to the whole numbers etc.  It's generalization and
> abstraction.  You don't learn all of that in elementary school.

Ok it has been extended. That is your conclusion. But why? Show me the use.

> > That there may be some convention is not excluded, and that there is
> > identity element in mathematics is fine, but even the page of identity
> > element does not speak of creation of identity elements, but of usage
> > of identity elements.
> 
> It's just not important enough, it's a little detail.  Like in Elisp.
> It might sound super important and big to you right now but we are
> speaking about a tiny corner case all the time.  We don't mention that
> (* 0 n) returns 0 in the docstring of `*', for example.

I do not see above as analogous. I wish though.

> > Then we have contradiction that description of functions `*' and `+'
> > and `-' does not speak of any sets or group theory. And we have people
> > speaking yes, group theory, sets. 
> >
> > But not description of relation from sets to Lisp function, why?
> 
> We have argument _lists_ that play the role of sets.
> 
> > I am asking why is it in (some) Lisps?
> 
> Because it's more convenient than raising an error.  Examples had been
> outlined in this thread.

OK, maybe that, I would like to understand if that was really the
reason of including it, the reason to minimize errors?

I remember keyword "variadic functions", and by you telling me that
reason is to minimize errors, then I searched and found following:

http://www.google.com/search?hl=en-UG&source=hp&biw=&bih=&q=reason+for+variadic+functions+in+lisp+%22%28*%29%22&iflsig=AK50M_UAAAAAY8bsWwouJNovTEERdNcNKZHzCAJ9q4qm&gbv=2&oq=reason+for+variadic+functions+in+lisp+%22%28*%29%22&gs_l=heirloom-hp.3..0i546l3j0i30i546.87530.93919.0.94212.43.40.0.1.1.1.283.4416.20j15j5.40.0....0...1ac.1.34.heirloom-hp..16.27.2252.UY2UeNCa7OY

I see one reference here:

Lots of Insipid, Stupid Parentheses | by Ronie Uliana | Medium:
https://ronie.medium.com/lots-of-insipid-stupid-parentheses-98f9b9510579

where it says:

"Variadic arguments are even more interesting when we don’t pass any argument, like this:

(+) <= this one gives us 0
(*) <= and this results in 1

Very handy because those are exactly the neutral elements for sum and
product."

But I can't see why is it handy, why it was added to Lisp to be
handy. I heard so far it is convenient, handy, but not why is it
convenient, no example where it shows its conveniency, and Picolisp
example shows that `apply' can work perfectly well even if (*) ➜ NIL

I can see here at this reference:

Lots of Insipid, Stupid Parentheses | by Ronie Uliana | Medium:
https://ronie.medium.com/lots-of-insipid-stupid-parentheses-98f9b9510579

> Variadic functions are functions that can take a variable number of
> arguments. In C programming, a variadic function adds flexibility to
> the program. It takes one fixed argument and then any number of
> arguments can be passed. The variadic function consists of at least
> one fixed variable and then an ellipsis(…) as the last parameter.

That gives me to think that the sole purpose of making (*) ➜ 1 work in
Lisp is to minimize errors, though I do not see the useful Lisp
expression where such error is minimized. I wish to find it. The only
useful case where I see that (*) will minimize errors is the function
itself, by writing "(*)" so in that case it minimizes errors, so that
demonstration is not enough.

Is there any other case or Lisp expression where one can see that (*)
is useful to minimize errors?

I can think that such case is maybe every day easy to find, but so far
none of participants mentioned it.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Eduardo Ochs]

On Tue, 17 Jan 2023 at 15:05, Jean Louis <bugs@gnu.support> wrote:
> Ok it has been extended. That is your conclusion. But why? Show me the use.

Hi Jean,

note that we are discussing several different operations called `+'...
and sometimes to understand what a mathematical sentence "really
means" we have to add annotations to these operations with the same
name to distinguish them. The best explanation that I know about this
is in the pages 15-20 of these slides:

http://math.andrej.com/asset/data/the-dawn-of-formalized-mathematics.pdf#page=15

When I had to explain "neutral elements" to my students a few months
ago I started by the operations "for all" and "exists". They
understood very quickly that for any proposition P(x) we had:

  ∀x∈{2,3,5}.P(x) = P(2)∧P(3)∧P(5)
  ∃x∈{2,3,5}.P(x) = P(2)∨P(3)∨P(5)

where "∧" is "and" and "∨" is "or", and these are the boolean "and"
and "or", that only accept inputs that are truth-values, and the only
truth-values are "true" and "false"... so these "∧" and "∨" are very
different from the "and" and "or" from Lisp.

Then at some point we started to meet expressions like these ones:

  ∀x∈{}.P(x)
  ∃x∈{}.P(x)

In a first moment the students didn't know how to interpret them. I
told them that this is one of the places in which mathematicians
_decide_ to extend a known operation, and in which they _choose_ an
extended definition that may look artificial at first - but they
choose a definition that turns out to be more well-behaved that the
other ones. For the "∀" we had (at least) these three possibilities:

  ∀x∈{}.P(x) = error
  ∀x∈{}.P(x) = false
  ∀x∈{}.P(x) = true

and I showed to them why the mathematicians had decided that this one

  ∀x∈{}.P(x) = true

would be the best choice. In my argument I used the figures that are here,

  http://angg.twu.net/LATEX/2022-2-C2-tudo.pdf#page=87

but these figures are not self-contained - I also talked a lot, wrote
lots of things on the whiteboard, and gesticulated a lot.

By the way, I started by "∀" and "∃" because I saw that it would be
better to start by them and then do "Σ" and "Π" later. See:

  https://en.wikipedia.org/wiki/Summation#Capital-sigma_notation

By the way: my main objective was to show to the students how
definitions work, and how in some cases some definitions can be
extended. "∀" and "∃" were just particular cases of this big idea, and
the big idea itself was more important than its particular cases.

  Cheers,
    Eduardo

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Do you have mathematical exercise in Lisp that may demonstrate it
> usefulness?
>
> Is it only for representation purposes like Eduardo explained,
> something like:
>
> (* 2 2 2) ➜ 8
> (* 2 2) ➜ 4
> (* 2) ➜ 2
> (*) ➜ 1
>
> Do you think it is only for representation or consistency purposes? Or
> there is some actual use?

The complete thing must be consistent, but anything must be consistent
to avoid false results, consistence is not the purpose.

The question of use is a valid one, we missed to answer it yet.  It
wasn't clear to me that this was part of what you are asking for.

Ok, I'll try to give an example.

You list your expenses in a form.  On six pages.  You write the sum of
all expenses of any page on the bottom of the page to be able to
calculate the final sum conveniently.

But on page 5 there are no expenses at all.  What do you write on the
bottom of that page?  You could write nothing, but then you might wonder
if you have forgotten to fill out that page.  You could also leave a
special note "no expenses" - but in Lisp we don't have such special
values that can be used in summation.  So you just write "0" onto that
page - the partial sum of no summands.  That works because adding 0
doesn't change the final result (as adding zero summands to the final
sum would) - it's the same in the case of summation: 0 is the "nothing"
of addition.

Likewise, 1 is the "nothing" of products and "" is the "nothing" of
string `concat'enation, etc.  This interpretation only makes sense when
the result of (+), (*), (concat) appears as intermediate result in some
other call of `+', `*', `concat'.  By themselves the value is not always
meaningful (0 as the value of the empty sum might be meaningful, 1 as
result of an empty product less, the empty string as results of
concatenating no strings -- depends).  But it allows to avoid to treat
the case of empty subsets specially.


> OK I understand people in Common Lisp included it, and Emacs Lisp has
> it, and other Lisps. But why for example Emacs Lisp has (-) ➜ 0 but
> other Lisps not?

That's also a valid question.

(-) and (/) are questionable.  `-' accepts one argument, so e.g. (- 7)
==> 7.  (/ 7.0) is also interpreted as value of 1/7.

I don't care about the results of (-) and (/), these are indeed a bit
obscure IMO.

Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 22:20]:
> The question of use is a valid one, we missed to answer it yet.  It
> wasn't clear to me that this was part of what you are asking for.

Yes, that one. 

Why authors decided to have (*) ➜ 1 which in case of me who could
delete some argument like from (* tonnes quantity) I could by mistake
delete "tonnes and quantity" and result of (*) would not be detected
because there is no error -- while makers (authors) of which Lisp, as
I do not know where did it start, maybe in Common Lisp, maybe in Emacs
Lisp, why did they decide to include it?

So let me read here:

> You list your expenses in a form.  On six pages.  You write the sum of
> all expenses of any page on the bottom of the page to be able to
> calculate the final sum conveniently.
> 
> But on page 5 there are no expenses at all.  What do you write on the
> bottom of that page?  You could write nothing, but then you might wonder
> if you have forgotten to fill out that page.  You could also leave a
> special note "no expenses" - but in Lisp we don't have such special
> values that can be used in summation.  So you just write "0" onto that
> page - the partial sum of no summands.  That works because adding 0
> doesn't change the final result (as adding zero summands to the final
> sum would) - it's the same in the case of summation: 0 is the "nothing"
> of addition.

Writing zero is one thing, surely I understand above. I said that I
did read the identity element article, and that articles does not
speak of absence of elements! It speaks that identity element is the
one when added to other elements, it does not change the result.

We have here case of absence of elements, not presence of
elements.

I understand your practical example above, I can't see relation to
Lisp where author made (*) to result with 1. Of course I understand
that some people say ah, there is set theory and that is identity
element, but practical use in multiplication or addition I still can't
find.

I got clue that having that identity element was maybe helpful in
other programming language like C, and then somebody started placing
it in Lisp arithmetic functions, where maybe it does not have any real
use. I may be wrong, but research of variadic functions kind of gives
me clue to that conclusion.

> Likewise, 1 is the "nothing" of products and "" is the "nothing" of
> string `concat'enation, etc.

I can't see that 1 is nothing for produts, but I understand what you
wish to say. 

If (*) ➜ 1 is "nothing", adding three "nothing" yields with 3:

(+ (*) (*) (*)) ➜ 3

which can't be, as nothing added to nothing can't give more than
nothing. However, I do understand what you wanted to say, just with
different terms.

> This interpretation only makes sense when the result of (+), (*),
> (concat) appears as intermediate result in some other call of `+',
> `*', `concat'.  By themselves the value is not always meaningful (0
> as the value of the empty sum might be meaningful, 1 as result of an
> empty product less, the empty string as results of concatenating no
> strings -- depends).  But it allows to avoid to treat the case of
> empty subsets specially.

I understand in Lisp context that various functions shall give me back
result, to help me with programming. But I do not see why would
(concat) ➜ "" not result with errors, I would like error there to be
reminded that I forgot something.

Maybe before programmer wish to write which strings are to be
concatenated, one can use function temporarily for testing, like

(let ((result (ignore))
       (my (concat))))
  my)

and then later this function becomes something like:

(let ((result (fetch-results))
       (my (concat "Result is: " result))))
  my)

For (concat) I can see use case as placeholder for string, so that
programmer can update the function.

Otherwise I don't know. Do you know use case for (concat)?

Some string functions I made I want them to give me empty string
instead of nil, but for concat I don't know why I would want that, I
want error.

For (*) I have not find use. Maybe use is in that temporary
programming moments, where programmer wish to add some numbers, but
did not add them yet, like following:

1. Programmer thinks of variables A multiplied by B 
    to be multiplied with C mutliplied by D

2. But writes without variables C and D: (* (* A B) (*))

3. Then in next step adds C and D: (* (* A B) (* C D))

Was that use case or something else that justified creation of (*) ➜ 1

Or was it just capricious thinking: "Let me add identity element, it
will look more like advanced mathematics"

Or was it the reason that it was maybe copied from C language which I
do not know, and which maybe got much more use of functions which
yield 1 for multiplication without any elements?

> > OK I understand people in Common Lisp included it, and Emacs Lisp has
> > it, and other Lisps. But why for example Emacs Lisp has (-) ➜ 0 but
> > other Lisps not?
> 
> That's also a valid question.
> 
> (-) and (/) are questionable.  `-' accepts one argument, so e.g. (- 7)
> ==> 7.  (/ 7.0) is also interpreted as value of 1/7.
> 
> I don't care about the results of (-) and (/), these are indeed a bit
> obscure IMO.

I understand you have no use for those, that is what maybe had some
use somewhere.

If you know C language, do you think that hypothesis that it simply
came from C language, could be right?


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> I can't see that 1 is nothing for produts, but I understand what you
> wish to say. 
>
> If (*) ➜ 1 is "nothing", adding three "nothing" yields with 3:
>
> (+ (*) (*) (*)) ➜ 3


You are still victim of a thinking error: you only think of counts of
things, counts of cars, etc.  But you can only _add_ counts of things, it
makes no sense to multiply counts of things.

Saying "I have no cars in my garage, but (*) ==> 1, so where is that car
out of nothing?" is equally nonsense as saying "A has 2 cars and B has 3
cars, and (* 2 3) ==> 6, but together they have only 5 cars, so where is
that car out of nothing?".  Multiplication of quantities is not meaningful
in this sense, it is the wrong operation, so there is no reason to
question the result when interpreting the result as a count of objects.


The following will be my last examples.

What kind of stuff in the real world could be multiply?  Maybe
multiplication rates of money?

Like, in year 1 you got 10 Percent interest on your investment.  3
percent in year 2.  In year 3 you did not invest your money, you were
ill all the time, or whatever.  In year 4 you got 4 percent.

The final interest is the product of interests in all years:

  1.1 * 1.03 * 1 * 1.04 = 1.17832

So 17.832 percent in those 4 years.  You could also leave out the third
factor 1.  But that might complicate your calculation unnecessarily.
The factor in year 3 can be assigned a number, it can be measured, even
when you "did nothing".  It's like the 0 in sums: adding a factor 1
doesn't change the result, so it plays the role of "nothing".  You did
not get "1 money" in that year.  That is a nonsense interpretation.
Those factors are not things like cars.  But they are useful for a
calculation.  It's a kind of abstraction.

Another example: transmission rates in a microscope.  Lenses attenuate
the beam of light through the microscope.  The final transmission rate
is the product of transmission rates of the parts.  Say every lens
takes away 10 percent of the transmission rate.  Say the objective A has 2
lenses, the middle part B no lenses, and the ocular 3 lenses, but two of
those are special very expensive lenses that take away only 1 percent:

The final transmission rate is (using Lisp syntax this time)

rate_A * rate_B * rate_C = ((* 0.9 0.9) (*) (* 0.9 0.99 0.99))
                         = (*     0.81   1   0.88209)
                         = 0.71449...

So you loose approx. 28.5 percent of light across the microscope.

That doesn't mean that the middle part adds a light beam or a
microscope.  These factors don't describe object counts.

> Otherwise I don't know. Do you know use case for (concat)?

Well, invent some, I think you are able to.  We have to stop here or
people get angry, this discussion has diverged away from Emacs.

> Or was it just capricious thinking: "Let me add identity element, it
> will look more like advanced mathematics"
>
> Or was it the reason that it was maybe copied from C language which I
> do not know, and which maybe got much more use of functions which
> yield 1 for multiplication without any elements?

No, none of that.  We are actually speaking about elementary maths, and
this is a useful handling of a corner case.

Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-18 16:39]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I can't see that 1 is nothing for produts, but I understand what you
> > wish to say. 
> >
> > If (*) ➜ 1 is "nothing", adding three "nothing" yields with 3:
> >
> > (+ (*) (*) (*)) ➜ 3

> You are still victim of a thinking error: you only think of counts of
> things, counts of cars, etc.  But you can only _add_ counts of things, it
> makes no sense to multiply counts of things.

I am not the one trying to explain things.

I look only at functions like:

(+ (*) (*) (*)) ➜ 3

which do not result that mathematically shall be sum of three
multiplications.

It is error in programming language.

Without trying to explain it, provide Lisp function where it is
actually useful.

Or otherwise, the research has shown so far:

1. nobody knows why is it useful in Lisp

2. various hypothesis have been tried out and tested. All with the
   attempt to justify how (*) ➜ 1 should be there, but none can find
   reason for (1), see aove.

3. there is no to me known piece of Emacs Lisp that would raise error
   if function `*' would be made to require two arguments, as this
   point (3) would lead to probable understanding of it.

and

4. Function makes something out of nothing instead of raising error: 
   (+ (*) (*) (*)) ➜ 3

> Saying "I have no cars in my garage, but (*) ==> 1, so where is that car
> out of nothing?"

Joke? It was joke.

> The following will be my last examples.
> 
> What kind of stuff in the real world could be multiply?  Maybe
> multiplication rates of money?

World examples are not object I am searching. I am searching how to
use (*) ➜ 1 in Lisp, and if there is no use, there is more use in
raising the error, then for capricious reasons of set theory lovers
spiting 1 as a result of multiplication of nothing.

I really don't mind of various mathematical theories, there are many,
but irrelevant stuff shall not be injected into simple multiplication.

So far you cannot tell me how is (*) ➜ 1 relevant for programmer, that
is what I am asking. Other stories in the world are only funny or
interesting, they do not help with Lisp.

> > Otherwise I don't know. Do you know use case for (concat)?
> 
> Well, invent some, I think you are able to.  We have to stop here or
> people get angry, this discussion has diverged away from Emacs.

Aha, the final conclusion is "it is there (*) ➜ 1" and please "don't
talk" or "Gods will get angry". 

> > Or was it the reason that it was maybe copied from C language which I
> > do not know, and which maybe got much more use of functions which
> > yield 1 for multiplication without any elements?
> 
> No, none of that.  We are actually speaking about elementary maths, and
> this is a useful handling of a corner case.

And instead of all of explanations, how about showing me how is it
useful?

I have shown how it is not useful:

   (+ (*) (*) (*)) ➜ 3

Where is example of how it is useful?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> I look only at functions like:
>
> (+ (*) (*) (*)) ➜ 3
>
> which do not result that mathematically shall be sum of three
> multiplications.

(*) is 1 because 1 is the neutral element of multiplication.
(+) is 0 because 0 is the neutral element of addition.

> It is error in programming language.
>
> Without trying to explain it, provide Lisp function where it is
> actually useful.
>
> Or otherwise, the research has shown so far:
>
> 1. nobody knows why is it useful in Lisp

It's useful because you can (apply #'+ my-list-of-numbers) and get a
correct result.

> 2. various hypothesis have been tried out and tested. All with the
>    attempt to justify how (*) ➜ 1 should be there, but none can find
>    reason for (1), see aove.
>
> 3. there is no to me known piece of Emacs Lisp that would raise error
>    if function `*' would be made to require two arguments, as this
>    point (3) would lead to probable understanding of it.
>
> and
>
> 4. Function makes something out of nothing instead of raising error: 
>    (+ (*) (*) (*)) ➜ 3
>
>> Saying "I have no cars in my garage, but (*) ==> 1, so where is that
>> car out of nothing?"
>
> Joke? It was joke.

The sum of cars in your garage is (apply #'+ nil) => 0 which is
absolutely correct.

>    (+ (*) (*) (*)) ➜ 3
>
> Where is example of how it is useful?

Well, replace + and * with `and' and `or' and you get the canonical
disjunctive or conjunctive normal forms.  And then you can use it with
lists of nil/non-nil values and it will be logically correct even when
an empty lists sneaks in which is essentially the constant t or nil in
this context.

Bye,
Tassilo

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Aha, the final conclusion is "it is there (*) ➜ 1" and please "don't
> talk" or "Gods will get angry". 

Honestly - this is how you talk to people after we already spent,
literally, hours of answering your questions?

Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-19 16:46]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Aha, the final conclusion is "it is there (*) ➜ 1" and please "don't
> > talk" or "Gods will get angry". 
> 
> Honestly - this is how you talk to people after we already spent,
> literally, hours of answering your questions?

Well -- you are free to draw conclusions. We may go through
encyclopedias and what, though answer to question why is it useful is
unknown.

When I say "useful" I wish to see that usefulness in Emacs Lisp.

Or maybe if it's origin is in Common Lisp or MacLisp, I wish to
understand from there.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Thu, Jan 19, 2023 at 05:42:27PM +0300, Jean Louis wrote:
> * Michael Heerdegen <michael_heerdegen@web.de> [2023-01-19 16:46]:
> > Jean Louis <bugs@gnu.support> writes:
> > 
> > > Aha, the final conclusion is "it is there (*) ➜ 1" and please "don't
> > > talk" or "Gods will get angry". 
> > 
> > Honestly - this is how you talk to people after we already spent,
> > literally, hours of answering your questions?
> 
> Well -- you are free to draw conclusions. We may go through
> encyclopedias and what, though answer to question why is it useful is
> unknown.
> 
> When I say "useful" I wish to see that usefulness in Emacs Lisp.
> 
> Or maybe if it's origin is in Common Lisp or MacLisp, I wish to
> understand from there.

MACLISP was one of the first LISPs around (way before Emacs, way before
you or me saw a computer). Serve yourself:

  http://www.maclisp.info/

Specifically here:

  http://www.maclisp.info/pitmanual/number.html

More specifically:

  http://www.maclisp.info/pitmanual/number.html#9.18

Those people did it this way... back in the 1970s because that's
the was mathematicians brains work. If they get to design an
n-ary addition or multiplication operator, /this/ is the way
they'd do it.

Emacs Lisp just inherited that. It was in LISP's "way of thinking"
right from the beginning.

Just because you don't like it it's not going to change.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: (*) -> 1

[Óscar Fuentes]

Jean Louis <bugs@gnu.support> writes:

> * Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 22:20]:
>> The question of use is a valid one, we missed to answer it yet.  It
>> wasn't clear to me that this was part of what you are asking for.
>
> Yes, that one. 
>
> Why authors decided to have (*) ➜ 1 which in case of me who could
> delete some argument like from (* tonnes quantity) I could by mistake
> delete "tonnes and quantity" and result of (*) would not be detected
> because there is no error

Throwing an error on this case is a reasonable possibility for the
language designers, but instead they decided to extend * to zero and one
arguments. Why? because it is convenient, because it makes possible to
do things like (apply '* some-list) without caring about how many
elements some-list has, which is handy when some-list comes from a place
you don't control. As far as the extension of * is reasonable, it is
nice to have, that's what the language designers thought.

So what's the reasonable extension of * (the variadic function!) to zero
arguments? Let's use some basic algebra:

(apply '* (list a b)) == (apply '* (list 1 1 a b))

which is the same as:

a * b == 1 * 1 * a * b

remove b:

a == 1 * 1 * a

remove a:

? == 1 * 1

which the same as:

(apply '* ()) == (apply '* (1 1))

or

(*) == (* 1 1)

So * applied to zero arguments shall be 1, because any other value would
break the equality.

Re: (*) -> 1

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [2023-01-18 16:58]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 22:20]:
> >> The question of use is a valid one, we missed to answer it yet.  It
> >> wasn't clear to me that this was part of what you are asking for.
> >
> > Yes, that one. 
> >
> > Why authors decided to have (*) ➜ 1 which in case of me who could
> > delete some argument like from (* tonnes quantity) I could by mistake
> > delete "tonnes and quantity" and result of (*) would not be detected
> > because there is no error
> 
> Throwing an error on this case is a reasonable possibility for the
> language designers, but instead they decided to extend * to zero and one
> arguments. Why? because it is convenient, because it makes possible to
> do things like (apply '* some-list) without caring about how many
> elements some-list has, which is handy when some-list comes from a place
> you don't control. 

That explanation sounds like neglect in programming. I have mentioned
that PicoLisp can `apply' with (*) yielding NIL. Try it out.

~$ pil
: (*)
-> NIL
: (+)
-> NIL
: (apply '* '(2 3))
-> 6

it means it is not really to give relief to other functions. And there
is nothing wrong for apply to yell the error when arguments are
missing to the function.

If you have some reference to that reasoning that (*) is related to
`apply' from language designer, let me know.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Óscar Fuentes]

Jean Louis <bugs@gnu.support> writes:

> * Óscar Fuentes <ofv@wanadoo.es> [2023-01-18 16:58]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > * Michael Heerdegen <michael_heerdegen@web.de> [2023-01-17 22:20]:
>> >> The question of use is a valid one, we missed to answer it yet.  It
>> >> wasn't clear to me that this was part of what you are asking for.
>> >
>> > Yes, that one. 
>> >
>> > Why authors decided to have (*) ➜ 1 which in case of me who could
>> > delete some argument like from (* tonnes quantity) I could by mistake
>> > delete "tonnes and quantity" and result of (*) would not be detected
>> > because there is no error
>> 
>> Throwing an error on this case is a reasonable possibility for the
>> language designers, but instead they decided to extend * to zero and one
>> arguments. Why? because it is convenient, because it makes possible to
>> do things like (apply '* some-list) without caring about how many
>> elements some-list has, which is handy when some-list comes from a place
>> you don't control. 
>
> 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?

> I have mentioned
> that PicoLisp can `apply' with (*) yielding NIL. Try it out.

The first thing written in PicoLisp's home page is:

   PicoLisp is quite different from other Lisps.

So be wary when taking PicoLisp's behavior as a comparison point when
discussing other Lisp implementations.

> ~$ pil
> : (*)
> -> NIL
> : (+)
> -> NIL
> : (apply '* '(2 3))
> -> 6

What's the output of

(apply '* '())

in PicoLisp?

> it means it is not really to give relief to other functions. And there
> is nothing wrong for apply to yell the error when arguments are
> missing to the function.
>
> 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.

Re: (*) -> 1

[Jean Louis]

* Óscar Fuentes <ofv@wanadoo.es> [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/

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Otherwise I don't know. Do you know use case for (concat)?

I have an idea for you: search for potential uses of calls of `*' and/or
`concat' (and maybe more associative functions) with no arguments in the
Emacs sources.  They exist and rely on the functions returning the
neutral argument and they are not really obscure.

Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-18 17:26]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Otherwise I don't know. Do you know use case for (concat)?
> 
> I have an idea for you: search for potential uses of calls of `*' and/or
> `concat' (and maybe more associative functions) with no arguments in the
> Emacs sources.  They exist and rely on the functions returning the
> neutral argument and they are not really obscure.

Did you find it? If you did, let me know. I do not know how to find
that.

Do you wish to say that (concat) ➜ "" yields empty string and that (*)
➜ 1 yields number one only for reason that it becomes easier to Emacs
developer to program in C language? In that case reasoning would be
awkward.

Or do you refer to Lisp? That is what I am searching.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Did you find it? If you did, let me know. I do not know how to find
> that.

Yes, I did.  After approximately 1 minute for every function I tried.
Believe it or not (I guess you don't believe it and add something weird
to your list instead that nobody can...etc. instead of starting to invest
your own time to really try to understand).

And no, I will not search those examples for you and discuss them with
you.  They are trivial to find and trivial to understand after reading
the things we explained.  And I already anticipate your reaction: that
that code is wrong and you expected different code.

I'm out.  Enough information has been presented to you to enable you to
learn.  But I cannot learn for you, you must do it yourself.


Michael.

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-19 16:56]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Did you find it? If you did, let me know. I do not know how to find
> > that.
> 
> Yes, I did.  After approximately 1 minute for every function I tried.
> Believe it or not (I guess you don't believe it and add something weird
> to your list instead that nobody can...etc. instead of starting to invest
> your own time to really try to understand).

You found examples I am searching, though you can't provide
references where (*) is useful.

And I said it is mystery made by Gods. Super beings who for unknown
reasons know everything, and do what they want, without knowledge
available for us human. 😉

Did you maybe find this in Emacs sources?

-*- mode: grep; default-directory: "~/Programming/Software/emacs/" -*-
Grep started at Thu Jan 19 17:44:12

find -H . -type d \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.src -o -path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) -prune -o \! -type d \( -name .\#\* -o -name \*.beam -o -name \*.vee -o -name \*.jam -o -name \*.o -o -name \*\~ -o -name \*.bin -o -name \*.lbin -o -name \*.so -o -name \*.a -o -name \*.ln -o -name \*.blg -o -name \*.bbl -o -name \*.elc -o -name \*.lof -o -name \*.glo -o -name \*.idx -o -name \*.lot -o -name \*.fmt -o -name \*.tfm -o -name \*.class -o -name \*.fas -o -name \*.lib -o -name \*.mem -o -name \*.x86f -o -name \*.sparcf -o -name \*.dfsl -o -name \*.pfsl -o -name \*.d64fsl -o -name \*.p64fsl -o -name \*.lx64fsl -o -name \*.lx32fsl -o -name \*.dx64fsl -o -name \*.dx32fsl -o -name \*.fx64fsl -o -name \*.fx32fsl -o -name \*.sx64fsl -o -name \*.sx32fsl -o -name \*.wx64fsl -o -name \*.wx32fsl -o -name \*.fasl -o -name \*.ufsl -o -name \*.fsl -o -name \*.dxl -o -name \*.lo -o -name \*.la -o -name \*.gmo -o -name \*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp -o -name \*.fn -o -name \*.ky -o -name \*.pg -o -name \*.tp -o -name \*.vr -o -name \*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o -name \*.tps -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) -prune -o  -type f \( -iname \*.el \) -exec grep --color=auto -i -nH --null -e \"\(\\\*\)\" \{\} +
./lisp/progmodes/verilog-mode.el:9311:	  ;; To advance past either "(*)" or "(* ... *)" don't forward past first *
./lisp/progmodes/verilog-mode.el:9783:	       ;; To advance past either "(*)" or "(* ... *)" don't forward past first *
./lisp/progmodes/verilog-mode.el:9977:	;; To advance past either "(*)" or "(* ... *)" don't forward past first *
./lisp/wid-edit.el:2569:  :on "(*)"
./lisp/international/latin1-disp.el:2319:	   (?\ "(*)")

Grep finished with 5 matches found at Thu Jan 19 17:44:48

I was reading about macros on Reddit

Why does lisp allow AND/OR operators to have 0 or 1 operands? : lisp:
https://www.reddit.com/r/lisp/comments/p3o25t/comment/h8vru39/

And I found some example of macro, it seems only that it saves some
time to programmer to write shorter macro rather than little longer
macro

https://www.reddit.com/r/lisp/comments/p3o25t/why_does_lisp_allow_andor_operators_to_have_0_or/h8vru39/?context=8&depth=9

But apart from similar mathematical explanations which do not lead to
answer how is it useful to somebody in Lisp, I did not find
enlightenment.

I can read by "stylwarning" user:

> It makes generalizing things easier and debugging easier. It also
> follows the arithmetic functions like + and * which allow zero or
> more arguments.

I can't find useful Lisp expression of "generalizing easier" with (*)
or "debugging easier" with (*).

> Simple example: I can comment out parts of an ABD/OR while debugging
> without having to rewrite the whole condition if I’m left with fewer
> than 2 cases.

That person indicates that the purpose would be temporary sketching of
functions. Though that I cannot get confirmed. For any bug in
programming language one could find some invented other purpose, why
not. It does not mean that authors intended it for that purpose of
sketching.

> A more complex example would involve writing macros. Say I’m writing
> a macro and I have an accumulated list of conditions CX I must
> satisfy. It is nice to be able to write

> `(and ,@cx)

> and not the comparatively annoying

> (cond
>   ((null cx) `t)
>   ((null (cdr cx)) (car cx))
>   (t `(and ,@cx)))



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> You found examples I am searching, though you can't provide references
> where (*) is useful.

Gosh, Jean, of course nobody would literally write (*) but (apply #'*
...), and you'll find occurrences in emacs:

--8<---------------cut here---------------start------------->8---
find -H . -type d \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o
-path \*/MCVS -o -path \*/.src -o -path \*/.svn -o -path \*/.git -o
-path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o
-path \*/\{arch\} \) -prune -o \! -type d \( -name .\#\* -o -name
\*.out -o -name \*.synctex.gz -o -name \*.o -o -name \*\~ -o -name
\*.bin -o -name \*.lbin -o -name \*.so -o -name \*.a -o -name \*.ln -o
-name \*.blg -o -name \*.bbl -o -name \*.elc -o -name \*.lof -o -name
\*.glo -o -name \*.idx -o -name \*.lot -o -name \*.fmt -o -name \*.tfm
-o -name \*.class -o -name \*.fas -o -name \*.lib -o -name \*.mem -o
-name \*.x86f -o -name \*.sparcf -o -name \*.dfsl -o -name \*.pfsl -o
-name \*.d64fsl -o -name \*.p64fsl -o -name \*.lx64fsl -o -name
\*.lx32fsl -o -name \*.dx64fsl -o -name \*.dx32fsl -o -name \*.fx64fsl
-o -name \*.fx32fsl -o -name \*.sx64fsl -o -name \*.sx32fsl -o -name
\*.wx64fsl -o -name \*.wx32fsl -o -name \*.fasl -o -name \*.ufsl -o
-name \*.fsl -o -name \*.dxl -o -name \*.lo -o -name \*.la -o -name
\*.gmo -o -name \*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp -o
-name \*.fn -o -name \*.ky -o -name \*.pg -o -name \*.tp -o -name \*.vr
-o -name \*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o
-name \*.tps -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) -prune
-o  -type f \( -iname \*.el \) -exec grep --color=auto -i -nH --null -e
\(apply\ \#\'\\\* \{\} +
./gnus/spam-stat.el:494:	 (prod (apply #'* probs))
./gnus/spam-stat.el:496:          (/ prod (+ prod (apply #'* (mapcar (lambda (x) (- 1 x))
./org/org-plot.el:232:    (apply #'* (org--plot/nice-frequency-pick weighted-factors))))
./org/org-plot.el:259:		  (< (* (apply #'* f-pick) 2-val) 30))
./org/org-plot.el:262:		  (< (* (apply #'* f-pick) 3-val) 30))
./htmlfontify.el:1055:    (let ((n (apply #'* m)))
--8<---------------cut here---------------end--------------->8---

And even more with (apply #'+ ...):

--8<---------------cut here---------------start------------->8---
find -H . -type d \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o
-path \*/MCVS -o -path \*/.src -o -path \*/.svn -o -path \*/.git -o
-path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o
-path \*/\{arch\} \) -prune -o \! -type d \( -name .\#\* -o -name
\*.out -o -name \*.synctex.gz -o -name \*.o -o -name \*\~ -o -name
\*.bin -o -name \*.lbin -o -name \*.so -o -name \*.a -o -name \*.ln -o
-name \*.blg -o -name \*.bbl -o -name \*.elc -o -name \*.lof -o -name
\*.glo -o -name \*.idx -o -name \*.lot -o -name \*.fmt -o -name \*.tfm
-o -name \*.class -o -name \*.fas -o -name \*.lib -o -name \*.mem -o
-name \*.x86f -o -name \*.sparcf -o -name \*.dfsl -o -name \*.pfsl -o
-name \*.d64fsl -o -name \*.p64fsl -o -name \*.lx64fsl -o -name
\*.lx32fsl -o -name \*.dx64fsl -o -name \*.dx32fsl -o -name \*.fx64fsl
-o -name \*.fx32fsl -o -name \*.sx64fsl -o -name \*.sx32fsl -o -name
\*.wx64fsl -o -name \*.wx32fsl -o -name \*.fasl -o -name \*.ufsl -o
-name \*.fsl -o -name \*.dxl -o -name \*.lo -o -name \*.la -o -name
\*.gmo -o -name \*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp -o
-name \*.fn -o -name \*.ky -o -name \*.pg -o -name \*.tp -o -name \*.vr
-o -name \*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o
-name \*.tps -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) -prune
-o  -type f \( -iname \*.el \) -exec grep --color=auto -i -nH --null -e
\(apply\ \#\'\+ \{\} +
./leim/quail/hangul.el:341:    (if (zerop (apply #'+ (append hangul-queue nil)))
./leim/quail/hangul.el:353:  (if (not (zerop (apply #'+ (append hangul-queue nil))))
./net/newst-backend.el:2186:  (apply #'+
./net/imap.el:1810:	(apply #'+ (mapcar #'imap-body-lines body)))
./net/shr.el:2350:    (let ((extra (- (apply #'+ (append suggested-widths nil))
./net/shr.el:2351:                    (apply #'+ (append widths nil))
./treesit.el:2608:          (eq 0 (apply #'+ (mapcar #'treesit-node-child-count children))))
./textmodes/texinfmt.el:2044:            (apply #'+ texinfo-multitable-width-list))))
./gnus/gnus-picon.el:217:		  (setq len (apply #'+ (mapcar (lambda (x)
./gnus/gnus-cache.el:889:	  (apply #'+ entry)
./gnus/gnus-score.el:2560:		 (apply #'+ (mapcar
./gnus/gnus-sum.el:3836:	    (apply #'+ (mapcar
./gnus/gnus-sum.el:8840:	       (apply #'+ (mapcar #'gnus-summary-limit-children
./gnus/gnus-agent.el:4139:	  (apply #'+ entry)
./gnus/spam-stat.el:515:      (apply #'+ scores))))
./calendar/solar.el:753:                (apply #'+
./calendar/solar.el:941:         (S (apply #'+ (mapcar (lambda(x)
./calendar/todo-mode.el:3697:  (mapcar (lambda (i) (apply #'+ (mapcar (lambda (x) (aref (cdr x) i))
./ses.el:625:	ses--linewidth  (apply #'+ -1 (mapcar #'1+ widths))
./ses.el:4037:  (apply #'+ (apply #'ses-delete-blanks args)))
./ses.el:4044:  (/ (float (apply #'+ list)) (length list)))
./org/org-plot.el:246:     (let* ((total-count (apply #'+ (mapcar #'cdr frequencies)))
./org/org-colview.el:1261:  (format (or printf "%s") (apply #'+ (mapcar #'string-to-number values))))
./org/org-colview.el:1265:  (format "%.2f" (apply #'+ (mapcar #'string-to-number values))))
./org/org-colview.el:1306:	  (/ (apply #'+ (mapcar #'string-to-number values))
./org/org-colview.el:1324:   (lambda (&rest values) (/ (apply #'+ values) (float (length values))))
./org/org-colview.el:1340:   (/ (apply #'+ (mapcar #'org-columns--age-to-minutes ages))
./org/org-clock.el:2626:	 (total-time (apply #'+ (mapcar #'cadr tables)))
./minibuffer.el:2025:				        (apply #'+ (mapcar #'string-width s))
./minibuffer.el:2068:                                           (apply #'+ (mapcar #'string-width str))
./pcomplete.el:943:          (let* ((envpos (apply #'+ (mapcar #' length strings)))
./progmodes/cc-guess.el:368:				 (apply #'+
./progmodes/sql.el:3639:          (apply #'+ (mapcar (lambda (ch) (if (eq ch ?\n) 1 0))
./progmodes/vhdl-mode.el:7480:		(apply #'+ (mapcar #'vhdl-get-offset syntax)))
./obsolete/thumbs.el:207:           (dirsize (apply #'+ (mapcar (lambda (x) (cadr x)) files-list))))
./obsolete/landmark.el:1428:  (apply #'+
./emacs-lisp/memory-report.el:254:    (apply #'+
./emacs-lisp/bytecomp.el:4515:    (let ((nvalues (apply #'+ (mapcar (lambda (case) (length (car case)))
./emacs-lisp/smie.el:2219:        (cl-assert (= total (apply #'+ (mapcar #'cdr off-alist))))
--8<---------------cut here---------------end--------------->8---

It's totally sensible to be able to compute the product/sum of an
arbitrary number of numbers.

All these would need checks for non-empty lists or even lists of at
least 2 numbers if + and * would require at least 1 or 2 arguments.

Bye,
Tassilo

Re: (*) -> 1

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2023-01-19 18:35]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > You found examples I am searching, though you can't provide references
> > where (*) is useful.
> 
> 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. 

Did you see reference to PicoLisp?

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Tassilo Horn]

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.

Well, in (+) there exists no argument evaluating to NIL and
mathematically, the sum of zero numbers is 0
(https://en.wikipedia.org/wiki/Empty_sum).  Same for the empty product
(*) which should be 1 (https://en.wikipedia.org/wiki/Empty_sum) but also
gives NIL in picolisp.

So why does it return NIL?  And why do you apparently consider that
useful?  And can something be useful even though it is incorrect?

Bye,
Tassilo

Re: (*) -> 1

[Jean Louis]

* 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/

Re: (*) -> 1

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

>> 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:09 <abu[m]> It is a "feature" that NIL propagates through
>                arithmetics

Well, but with (*) and (+), there is no single NIL involved!  And in
Elisp (+ nil), where actually a nil is involved, you get an error.

> 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:12 <abu[m]> What is a call like (*) useful for?
>
> As you see, author also asked naturally why is it useful.

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.

>> 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.

It's good to signal an error when the expression is wrong as does Elisp
with

  (+ nil)
  (* 1 2 nil)
  (apply #'+ (list 1 nil 19))
  (+ 2 "i am not a number")

but when there is no nil or otherwise wrongly typed value involved,
there's nothing to signal.

Bye,
Tassilo

Re: (*) -> 1

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2023-01-20 16:14]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> 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:09 <abu[m]> It is a "feature" that NIL propagates through
> >                arithmetics
> 
> 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 (*) ➜ 1
and that programs work, GUI applications and Android/Replicant work,
and there was no use of (*) ➜ 1 so far.

Similarly like author of PicoLisp finding use when (*) ➜ NIL, so I
would also find (very rare) use with errors. Even if NIL, I find use
as I will get error raised in combinations like (+ (*) (* 2 2)),
because (+ nil 4) would raise error.

> > 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:12 <abu[m]> What is a call like (*) useful for?
> >
> > As you see, author also asked naturally why is it useful.
> 
> 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.

But docstring does not speak of empty sets. You introduce "sets" where
there is not direct relation to it.

(+ &rest NUMBERS-OR-MARKERS)

Return sum of any number of arguments, which are numbers or
markers. Of course I get confused.

I ask A, but people say B. 
I ask A, but people say C.
I ask A, but people say D.

No answer about A. But there are many introductions of things not
relevant to function itself. 

I still believe that there is some actual practical use.

`apply' can be used with (apply '+ '(a b)) as why would you need in
apply for addition two arguments?

If list is with one argument, testing with `cadr' will be known,
otherwise, I use `car' instead of `apply'.

> >> 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.
> 
> It's good to signal an error when the expression is wrong as does Elisp
> with
> 
>   (+ 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. Making
it less error prone with useless default identity elements hides the
real event preceding the operation.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

>> >> 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:09 <abu[m]> It is a "feature" that NIL propagates through
>> >                arithmetics
>> 
>> 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 (*) ➜ 1
> and that programs work, GUI applications and Android/Replicant work,
> and there was no use of (*) ➜ 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 <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:12 <abu[m]> What is a call like (*) useful for?
>> >
>> > As you see, author also asked naturally why is it useful.
>> 
>> 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
>> 
>>   (+ 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

Re: (*) -> 1

[Emanuel Berg]

Tassilo Horn wrote:

> 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.

Your book? Actually I think a lot of people have it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: (*) -> 1

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-01-22 08:55]:
> Tassilo Horn wrote:
> 
> > 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.
> 
> Your book? Actually I think a lot of people have it.

Question is resolved.

I have re-defined (*) ➜ 1 to give me at least something useful:

(defun * ()
  "sex")

(*) ➜ "sex"


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Emanuel Berg]

Jean Louis wrote:

>>> 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.
>> 
>> Your book? Actually I think a lot of people have it.
>
> Question is resolved.
>
> I have re-defined (*) → 1 to give me at least something
> useful:
>
> (defun * ()
>   "sex")
>
> (*) → "sex"

The No. 1 thing to some people ...

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: (*) -> 1

[Drew Adams]

> > (*) → "sex"
> The No. 1 thing to some people ...

We pretty much _all_ depend on it.

Until we start cloning people or we
develop human parthenogeny.

(There's in vitro fertilization, but
you still need two sexes there.)

Oh, sorry, didn't mean to leave out
the miracle of virgin birth.

Miracles aside, sex is pretty helpful.

Re: (*) -> 1

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 6158 bytes --]

Emanuel Berg <incal@dataswamp.org> writes:

> Tassilo Horn wrote:
>
>> 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.
>
> Your book? Actually I think a lot of people have it.

I just made a language named "Emacs Lisp Fuck", and here's the
"Hello, World!" program:

#+begin_src emacs-lisp
(string
 (+(*)(+)(*)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(+)(+)(*)(*)(*)(*)(+)(*)(*)
   (*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(+)(*)(+)(*)(*)(*)
   (*)(+)(+)(+)(*)(+)(*)(*)(+)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(+)
   (*)(*)(*)(+)(+)(*)(*)(+)(+)(+)(*)(+)(+)(+)(+)(*)(*)(+)(*)(+)(*)(*)
   (+)(*)(+)(+)(*)(+)(*)(+)(*)(*)(*)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(+)
   (*)(+)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(+)(+)(+))
 (+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(*)(*)(+)(*)(*)(+)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(*)(*)(+)(*)
   (*)(*)(+)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)
   (*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(+)(+)(*)(+)(*)(*)(+)(*)(+)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)
   (*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(+)(*))
 (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
   (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
   (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
 (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
   (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
   (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
 (+(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)
   (*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
   (*)(*)(+)(+)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(+)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*))
 (+(+)(+)(+)(+)(+)(*)(+)(+)(*)(*)(+)(+)(*)(+)(+)(+)(+)(*)(+)(+)(*)(*)
   (*)(+)(+)(+)(*)(+)(+)(*)(+)(*)(+)(*)(*)(+)(+)(*)(+)(+)(+)(*)(*)(+)
   (+)(*)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(+)(+)(+)
   (*)(+)(*)(*)(+)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(*)(*)(+)(+)
   (+)(+)(*)(+)(*)(+)(+)(+)(+)(*)(*)(+)(+)(*)(+)(*)(*)(+)(+)(+)(*)(+)
   (*)(+)(+)(+)(+)(*)(*)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(+))
 (+(+)(*)(+)(*)(+)(+)(+)(+)(+)(*)(*)(*)(+)(*)(+)(*)(+)(*)(+)(*)(+)(+)
   (+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(*)(+)(+)(+)
   (*)(*)(+)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(*)
   (+)(+)(*)(*)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)
   (+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(+)(*)(*)(+)(*)
   (+)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*))
 (+(*)(+)(*)(+)(+)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(+)(+)(*)(+)(+)(+)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(*)(+)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(+)(*)
   (+)(+)(*)(*)(*)(+)(+)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(+)(+)(+)(+)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)
   (*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*))
 (+(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)
   (*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
   (*)(*)(+)(+)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(+)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*))
 (+(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(+)(+)(+)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(+)
   (*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
 (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
   (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
   (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
   (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
 (+(+)(*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)
   (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)
   (*)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
   (*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(+)(*)
   (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(*)
   (*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(+)(*)(*)(+)(*))
 (+(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(+)(*)(*)(*)(+)
   (+)(*)(+)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(+)(+)(+)(+)(+)(*)(+)(+)(+)
   (+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(*)(+)(+)(*)(+)(+)(+)
   (+)(+)(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(*)(+)
   (+)(*)(+)(+)(*)(+)(*)(+)(+)(*)(+)(+)(+)(*)(*)(*)(+)(+)(*)(+)(+)(+)
   (+)(*)(+)(+)(*)(*)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(*)(+)))
#+end_src

Even I don't know how this works!

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: (*) -> 1

[Emanuel Berg]

Akib Azmain Turja wrote:

>>> 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.
>>
>> Your book? Actually I think a lot of people have it.
>
> I just made a language named "Emacs Lisp Fuck", and here's
> the "Hello, World!" program:
>
> (string
>  (+(*)(+)(*)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(+)(+)(*)(*)(*)(*)(+)(*)(*)
>    (*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(+)(*)(+)(*)(*)(*)
>    (*)(+)(+)(+)(*)(+)(*)(*)(+)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(+)
>    (*)(*)(*)(+)(+)(*)(*)(+)(+)(+)(*)(+)(+)(+)(+)(*)(*)(+)(*)(+)(*)(*)
>    (+)(*)(+)(+)(*)(+)(*)(+)(*)(*)(*)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(+)
>    (*)(+)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(+)(+)(+))
>  (+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(*)(*)(+)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(*)(*)(+)(*)
>    (*)(*)(+)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)
>    (*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(+)(+)(*)(+)(*)(*)(+)(*)(+)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(+)(*))
>  (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
>    (*)(*)(+)(+)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(+)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*))
>  (+(+)(+)(+)(+)(+)(*)(+)(+)(*)(*)(+)(+)(*)(+)(+)(+)(+)(*)(+)(+)(*)(*)
>    (*)(+)(+)(+)(*)(+)(+)(*)(+)(*)(+)(*)(*)(+)(+)(*)(+)(+)(+)(*)(*)(+)
>    (+)(*)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(+)(+)(+)
>    (*)(+)(*)(*)(+)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(*)(*)(+)(+)
>    (+)(+)(*)(+)(*)(+)(+)(+)(+)(*)(*)(+)(+)(*)(+)(*)(*)(+)(+)(+)(*)(+)
>    (*)(+)(+)(+)(+)(*)(*)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(+))
>  (+(+)(*)(+)(*)(+)(+)(+)(+)(+)(*)(*)(*)(+)(*)(+)(*)(+)(*)(+)(*)(+)(+)
>    (+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(*)(+)(+)(+)
>    (*)(*)(+)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(*)
>    (+)(+)(*)(*)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)
>    (+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(+)(*)(*)(+)(*)
>    (+)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*))
>  (+(*)(+)(*)(+)(+)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(+)(+)(*)(+)(+)(+)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(*)(+)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(+)(*)
>    (+)(+)(*)(*)(*)(+)(+)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(+)(+)(+)(+)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)
>    (*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*))
>  (+(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
>    (*)(*)(+)(+)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(+)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*))
>  (+(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(+)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(+)
>    (*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(+)(*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(+)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(+)(*)(*)(+)(*))
>  (+(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(+)(*)(*)(*)(+)
>    (+)(*)(+)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(+)(+)(+)(+)(+)(*)(+)(+)(+)
>    (+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(*)(+)(+)(*)(+)(+)(+)
>    (+)(+)(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(*)(+)
>    (+)(*)(+)(+)(*)(+)(*)(+)(+)(*)(+)(+)(+)(*)(*)(*)(+)(+)(*)(+)(+)(+)
>    (+)(*)(+)(+)(*)(*)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(*)(+)))
>
> Even I don't know how this works!

Haha :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: (*) -> 1

[Jean Louis]

* Akib Azmain Turja <akib@disroot.org> [2023-01-22 17:37]:
> I just made a language named "Emacs Lisp Fuck", and here's the
> "Hello, World!" program:

I knew it, as I already got it (ouch) on the mailing list.

> #+begin_src emacs-lisp
> (string
>  (+(*)(+)(*)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(+)(+)(*)(*)(*)(*)(+)(*)(*)
>    (*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(+)(*)(+)(*)(*)(*)
>    (*)(+)(+)(+)(*)(+)(*)(*)(+)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(+)
>    (*)(*)(*)(+)(+)(*)(*)(+)(+)(+)(*)(+)(+)(+)(+)(*)(*)(+)(*)(+)(*)(*)
>    (+)(*)(+)(+)(*)(+)(*)(+)(*)(*)(*)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(+)
>    (*)(+)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(+)(+)(+))
>  (+(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(*)(*)(+)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(*)(*)(+)(*)
>    (*)(*)(+)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)
>    (*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(+)(+)(*)(+)(*)(*)(+)(*)(+)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(+)(*))
>  (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
>    (*)(*)(+)(+)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(+)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*))
>  (+(+)(+)(+)(+)(+)(*)(+)(+)(*)(*)(+)(+)(*)(+)(+)(+)(+)(*)(+)(+)(*)(*)
>    (*)(+)(+)(+)(*)(+)(+)(*)(+)(*)(+)(*)(*)(+)(+)(*)(+)(+)(+)(*)(*)(+)
>    (+)(*)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(+)(+)(+)
>    (*)(+)(*)(*)(+)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(*)(*)(+)(+)
>    (+)(+)(*)(+)(*)(+)(+)(+)(+)(*)(*)(+)(+)(*)(+)(*)(*)(+)(+)(+)(*)(+)
>    (*)(+)(+)(+)(+)(*)(*)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(+))
>  (+(+)(*)(+)(*)(+)(+)(+)(+)(+)(*)(*)(*)(+)(*)(+)(*)(+)(*)(+)(*)(+)(+)
>    (+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(*)(+)(+)(+)
>    (*)(*)(+)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(*)
>    (+)(+)(*)(*)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)
>    (+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(+)(+)(+)(+)(*)(*)(+)(*)
>    (+)(*)(*)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*))
>  (+(*)(+)(*)(+)(+)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(+)(+)(*)(+)(+)(+)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(*)(+)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(+)(*)
>    (+)(+)(*)(*)(*)(+)(+)(*)(*)(*)(+)(+)(+)(+)(*)(*)(*)(+)(+)(+)(+)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)
>    (*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*))
>  (+(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
>    (*)(*)(+)(+)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(+)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(+)(*)(*))
>  (+(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(+)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(+)
>    (*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
>    (*)(*)(*)(*)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))
>  (+(+)(*)(*)(*)(+)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)
>    (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(+)(+)(*)(*)(*)
>    (*)(*)(*)(*)(+)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)(+)(+)(*)(*)(*)(*)(*)
>    (*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(*)(+)(*)(+)(*)(*)(+)(*)
>    (*)(*)(+)(*)(+)(*)(+)(*)(*)(*)(+)(*)(*)(*)(*)(*)(*)(+)(*)(*)(+)(*)
>    (*)(*)(*)(*)(*)(+)(*)(*)(*)(+)(*)(*)(+)(+)(*)(*)(+)(*))
>  (+(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(+)(*)(*)(*)(+)
>    (+)(*)(+)(+)(+)(+)(+)(*)(+)(*)(+)(*)(*)(+)(+)(+)(+)(+)(*)(+)(+)(+)
>    (+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(+)(+)(+)(+)(*)(*)(+)(+)(*)(+)(+)(+)
>    (+)(+)(+)(+)(*)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(+)(*)(*)(+)
>    (+)(*)(+)(+)(*)(+)(*)(+)(+)(*)(+)(+)(+)(*)(*)(*)(+)(+)(*)(+)(+)(+)
>    (+)(*)(+)(+)(*)(*)(+)(+)(+)(+)(*)(+)(+)(*)(+)(+)(*)(+)))
> #+end_src
> 
> Even I don't know how this works!

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Jean Louis]

* Akib Azmain Turja <akib@disroot.org> [2023-01-22 17:37]:
> I just made a language named "Emacs Lisp Fuck", and here's the
> "Hello, World!" program:

It needs a package.

(defun elbf-char (n)
  (concat "(+ " (string-replace "*" "(*)" (make-string n ?*)) ")"))

(defun elbf-string (string)
  (let ((list (string-to-list string)))
    (with-temp-buffer
      (insert "(string ")
      (while list
	(insert (elbf-char (pop list))))
      (insert ")")
      (buffer-string))))

(elbf-string "Hello") ➜ (string (+ (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+ (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+ (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+ (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))(+ (*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*))) ➜ "Hello"

  
-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Emanuel Berg]

Jean Louis wrote:

> (defun elbf-char (n)
>   (concat "(+ " (string-replace "*" "(*)" (make-string n ?*)) ")"))
>
> (defun elbf-string (string)
>   (let ((list (string-to-list string)))
>     (with-temp-buffer
>       (insert "(string ")
>       (while list
> 	(insert (elbf-char (pop list))))
>       (insert ")")
>       (buffer-string))))

Not bad!

Only: Hard coding the same data several times -> court martial.

But it's not like there is real punishment or anything ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: (*) -> 1

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> You found examples I am searching, though you can't provide
> references where (*) is useful.

I don't want to spend more time in this discussion.  And please stop
blaming me for "what I can" or what people can or can't.  I just don't
have fun in this discussion any more.  Please just respect that.

Michael.

Re: (*) -> 1

[Dr Rainer Woitok]

Jean Louis,

On Thursday, 2023-01-19 17:54:16 +0300, you wrote:

> ...
> You found examples I am searching, though you can't provide
> references where (*) is useful.
> 
> And I said it is mystery made by Gods. Super beings who for unknown
> reasons know everything, and do what they want, without knowledge
> available for us human.

Sorry, I'm late in this discussion.   And to explain why this has not to
do with Gods but rather with simple mathematics, I need to know a little
bit about your  math knowledge.   It's ok if you don't want to answer my
questions, but then it doesn't make sense for me to continue explaining.

Question 1: Do you know the meaning of "rising x to the power of n"?

On paper this is written like so

    n
   x

and in plenty of programming languages it's written as "x^n" or "x**n".

If you are familiar with this concept, and if you want to continue this,
simply reply to this mail.

Sincerely,
  Rainer

Re: (*) -> 1

[Jean Louis]

* Dr Rainer Woitok <rainer.woitok@gmail.com> [2023-01-19 20:39]:
> Sorry, I'm late in this discussion.   And to explain why this has not to
> do with Gods but rather with simple mathematics, I need to know a little
> bit about your  math knowledge.

Thanks, though it is not related to my question.

My question is related to why or how is it useful in Lisp.

Apart from "minimizing error handling in some situation" or "sketching
of programs" or "shortening of macros", can you demonstrate me how it
is useful in Lisp?

Let me demonstrate the vague use that was so far discovered:
------------------------------------------------------------


Example of sketching of program:
--------------------------------

User thinks of list, but does not place it:

(let ((my-factor-1 1)
      (my-factor-2 2)
      (my-factor-3 3)
      (my-factor-4 4))
  (+ (*) (* my-factor-3 my-factor-4 )))

then in the next step user does place the elements:

(let ((my-factor-1 1)
      (my-factor-2 2)
      (my-factor-3 3)
      (my-factor-4 4))
  (+ (* my-factor-1 my-factor-2) (* my-factor-3 my-factor-4 )))

I can't say that above is good usage example, as in fact, programmer
may forget that he wrote (*) and may get result without being warned
that factors are missing.


Example of minimizing errors:
-----------------------------

(setq my-list '())

(apply #'* '(2 3 4)) ➜ 24
(apply #'* my-list) ➜ 1

However, in that case programmer could forget to put something in the
list, and raising of error is more important for empty list or missing
arguments, than just yielding 1.

Minimizing errors means neglecting the function and unexpected
results. Function `apply' and `reduce' can as well take any kind of
functions that require zero or more arguments.

When let us say a list has only single element and I wish to `apply'
addition on such list, then I can just give that single element as
result instead of running function on single list element. So that is
matter of programming style and care.

It does not really answer my question where is (*) useful.


Missing example of macro minimization
-------------------------------------

In that example programmer would write shorter macro when function
does not require 2 factors and somewhat longer where function require
two arguments.


Example of fun with (*)
-----------------------

(defun m (n)
  (let ((m))
  (dotimes (b n)
    (setq m (cons "(*)" m)))
  (concat "(+" (string-join m) ")")))

(let ((first 1))
  (insert "\n")
  (while (<= first 10)
    (let ((second 1))
      (while (<= second 10)
	(insert "(*" (m first)(m second) ")\n")
	(setq second (1+ second)))
      (setq first (1+ first)))))


Other example of fun with (*)
-----------------------------

(+ (*) (*) (*) (*) (*) (*)) ➜ 6


Or maybe function was made for mathematics lovers?
--------------------------------------------------

(*) ➜ 1

Just "because" we love mathematics.


The unanswered question:
------------------------

Do you know the actual practical example in any Lisp which will show
how (*) ➜ 1 is useful?

I do not ask how there are some "laws" outside of Lisp and because of
those laws somebody liked them and included in a function. That sounds
capricious.

To find useful function, we may find which program or function CANNOT
be executed (with slight modification) if I would make multiplication
to require 2 factors?



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Dr Rainer Woitok]

Jean Louis,

On Friday, 2023-01-20 10:31:36 +0300, you wrote:

> ...
> >                                                  I need to know a little
> > bit about your  math knowledge.
> 
> Thanks, though it is not related to my question.
> 
> My question is related to why or how is it useful in Lisp.

Oh.   Are you really going to say that an incorrect mathematical concept
of arithmetic would be more useful in Lisp?

Sincerely,
  Rainer

Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-19 16:56]:
> I'm out.  Enough information has been presented to you to enable you to
> learn.  But I cannot learn for you, you must do it yourself.

I did not ask for outside information, only if it is useful in Lisp,
apart from funny jokes and sketching of program.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: (*) -> 1

[Drew Adams]

> I'm out.  Enough information has been
> presented to you to enable you to learn.
> But I cannot learn for you, you must do
> it yourself.
> Michael.

Bingo.  Ditto.  Shoulda just considered it
as trolling perhaps.  In any case, shoulda 
stopped trying to help long ago.  Gave the 
benefit of the doubt; wasted time helping.
Maybe Dunning-Kruger?  Whatever.

Re: [External] : Re: (*) -> 1

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Bingo.  Ditto.  Shoulda just considered it
> as trolling perhaps.  In any case, shoulda
> stopped trying to help long ago.  Gave the
> benefit of the doubt; wasted time helping.
> Maybe Dunning-Kruger?  Whatever.

Exactly my thoughts.  This was really grotesque.  He just didn't even
recognize how much energy people invested trying to help.  Or maybe he
was just waiting for someone saying he is right instead of caring about
other answers.

Eli had the right intuition.

Michael.

Re: [External] : Re: (*) -> 1

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2023-01-20 00:31]:
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > Bingo.  Ditto.  Shoulda just considered it
> > as trolling perhaps.  In any case, shoulda
> > stopped trying to help long ago.  Gave the
> > benefit of the doubt; wasted time helping.
> > Maybe Dunning-Kruger?  Whatever.
> 
> Exactly my thoughts.  This was really grotesque.  He just didn't even
> recognize how much energy people invested trying to help.  Or maybe he
> was just waiting for someone saying he is right instead of caring about
> other answers.

And now because you have not found use in Lisp, which I still believe
must exist, or could exist in some early Lisp, all what you are left
is to go with the mob and participate in profanities.

I did not ask neither force you, or hired you, to give me X number of
mathematical theories.

I have asked how is that useful in Lisp. Because I can also make a
function like (defun i-like-it () (message "i-like-it")) and claim
that it is alright to result with "I like it" because I like
it. However, that does not have practical use for people. And that is
the foundation of my question, no matter how much Lisp authors liked
mathematics.

You participate voluntary in conversation. It is not employment. You
do not need to participate in any conversation. 

I am not waiting for anybody to tell me how I am wrong, or right.

I want to understand what was meant with making (*) ➜ 1 in the first
place.

So far I can only see that set theory is included because it exists,
and because somebody liked it, or was thinking it should be so.

I cannot see the practical use of it.

You could as well tell "I do not know any practical use of it", and
leave out of conversation.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: (*) -> 1

[Emanuel Berg]

Jean Louis wrote:

> You participate voluntary in conversation. It is not
> employment. You do not need to participate in
> any conversation.

... what do you mean, I'm not getting paid either?

> I want to understand what was meant with making (*) → 1 in
> the first place.

So it can be used when there sometimes is nothing to use it
on, and the end result won't be ruined but that occasion.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: (*) -> 1

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-01-19 20:47]:
> > I'm out.  Enough information has been
> > presented to you to enable you to learn.
> > But I cannot learn for you, you must do
> > it yourself.
> > Michael.
> 
> Bingo.  Ditto.  Shoulda just considered it
> as trolling perhaps.  In any case, shoulda 
> stopped trying to help long ago.  Gave the 
> benefit of the doubt; wasted time helping.
> Maybe Dunning-Kruger?  Whatever.

My question was pretty clear from beginning. I did not ask for
theories, I was asking for for practical usage example in Lisp.

If you challenge me to use profanities, I can do that better than you.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: (*) -> 1

[Anders Munch]

Michael Heerdegen:
>> Jean Louis: ..
> Sorry to be direct like this, but what you are doing had been quite unfriendly for a while now.

Being the only one who holds an opinion is not an unfriendly act.

The thread goes on because so many other people feel they ought to be able to convince him.
Just make peace with the idea that you won't convince him, and any perceived unfriendliness will stop.

> You don't listen to [...] what people write.
And the people who keep making analogies, instead of focusing on the Lisp functions, are not listening to what Jean Louis writes.
The thread seems perfectly courteous to me, but if you must critique the tone, try applying the same critical eye to the people that you agree with.

> You don't [...] understand what people write.
Not understanding is not an unfriendly act.

regards, Anders

Re: (*) -> 1

[Michael Heerdegen]

Anders Munch <ajm@flonidan.dk> writes:

> > You don't [...] understand what people write.
> Not understanding is not an unfriendly act.

Not trying to would be.  I got the impression he didn't try and got
angry.  Maybe I was wrong, then I'm sorry.

Michael.

Re: (*) -> 1

[Emanuel Berg]

Michael Heerdegen wrote:

>>> You don't [...] understand what people write.
>>
>> Not understanding is not an unfriendly act.
>
> Not trying to would be. I got the impression he didn't try
> and got angry. Maybe I was wrong, then I'm sorry.

It's OK ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: (*) -> 1

[Eli Zaretskii]

> From: Anders Munch <ajm@flonidan.dk>
> Date: Wed, 18 Jan 2023 09:02:11 +0000
> 
> Just make peace with the idea that you won't convince him, and any perceived unfriendliness will stop.

This whole thread should have moved to emacs-tangents long ago.

Re: (*) -> 1

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> This whole thread should have moved to emacs-tangents long ago.

The thread is partly about the interpretation and understanding of a
mathematical operation.  But it is also a question about Elisp and it's
usage, and understanding existing Elisp code, it matters in practice, so
emacs-help does not seem wrong to me.  It's also not wrong IMO to have
these answers in the archives, others may have the same question, and
understanding the background helps to remember the conventions.  That's
why I continued debating here.

Michael.

(*) -> 1

[Jean Louis]

* Andreas Eder <a_eder_muc@web.de> [2023-01-17 15:20]:
> > For now vague purpose is only to satisfy some other functions which
> > process lists, like `reduce' or `apply', I am searching for
> > confirmation if that was the sole purpose.
> 
> The purpose is to be consistent in a mathematical sense.
> There empty products are 1 and empty sums are 0. That is the only to
> sensibly define it and to  fulfill the associative property of the
> operations.

There are different contexts:

- mathematical sense whereby "+" always require addends, without it,
  there is nothing to add. A number like zero is alright, but it must
  be there.

- in lisp no addend is needed to yield (+) ➜ 0

- there is convention of identity elements, fine, but I do not see
  relation to above, neither why is one convention nullified in favor
  of the other convention

Then we have:

- mathematical sense whereby "*" always require 2 factos, without it,
  there is nothing to multiply. That is also convention. 

- in lisp no factor is needed to yield (*) ➜ 1

- because some other convention is followed nullyfing the previously
  explained one.

Still I have not find clear relation why is it so.

It is definitely not in every Lisp that way.

PicoLisp does not think so:

$ pil
: (+)
-> NIL
: (*)
-> NIL

and it handles properly function `apply' without having (+) ➜ 0:
----------------------------------------------------------------

: (apply '+ '(1 2 3 4))
-> 10

(apply '* '(1 2 3 4))
-> 24

Emacs Lisp:

(-) ➜ 0

but Guile:

-)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong number of arguments to -

So there are differences and the question is still open why is Lisp
using those identity elements.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/