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

[Jean Louis <bugs@gnu.support>]

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/