help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jean Louis
Subject: Re: [External] : Re: How to make M-x TAB not work on (interactive) declaration?
Date: Wed, 18 Jan 2023 17:32:44 +0300
User-agent: Mutt/2.2.9+54 (af2080d) (2022-11-21)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]