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