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

[Drew Adams <drew.adams@oracle.com>]

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