50g System RPL list processing

[Claudio L.]

(10-28-2014 03:56 PM)Gilles Wrote:  It's not logical at all ( '+' and 'ADD' should be invert) but I think it was necessary for backward compatibility with the very earliest RPL calcs without parallel processing (28 and 48 SX?) and the bad choice of + for ADD at this time.

Invert '+' and 'ADD' would be logical but you break the backward compatibility.

I already did for newRPL. In newRPL + behaves as I was showing above (as it should be?).

(10-28-2014 03:56 PM)Gilles Wrote:  With Gofer List :

{ } Sum gives 0
{ } Product gives 1

I dont understand your point of view about about "an empty list of reals or an empty list of strings"... From a User RPL point of view an empty list is ... an empty list. . An other choice could be to return NULL or NOVAL ?

My point exactly. An empty list is an empty list. What makes you think the sum should be a real number 0? why not an empty string? why not a zero vector with 2 components? or 3 components? or a NxN zero matrix?
There's no way of knowing what the list would've contained if it wasn't empty, so the result should be an error, you can't determine what the result should be (it has to be the null vector in the same vector space of a list full of items, be it matrices, vectors, scalars or any other object, but which one?).
returning NULL is about the same as an error (the user has to catch it or prevent this condition or their code will likely fail), except the concept of NULL is not defined in RPL (perhaps should be nil like in LISP?) so it would feel like a weird quirk of just one set of functions, rather than a feature of the language (like nil is in LISP).