Wish list

[kks]

Thanks Lutz for clarifications

[Kazimir Majorinc]

I think kks's proposal for (nth L 100000...) = nil is not unreasonable. It is analogous to



(1) Previously undefined variables, if used for first time, have value nil

(2) Some functions, for example, find or exists return nil if they cannot return value caller asked for.



Ambiguity, however, exists. For example, if function call](exists (lambda(x)(not (integer? x))) L)[/b]



returns nil, we cannot be sure whether L actually contains nil, or it contains only integers.



But, what caused the problem? In my opinion, problem is in function exists which returns two information compressed in one value. One information is: is there any non-integer in L? Other information is - if there is non-integer in L, which one is that? In most cases, we can compress these two information, but if that non-integer is the same value we use to inform that all members of L are integers, we're lost.



Why we readily use such compression? Because if it works correctly, and it does in most of the cases, it is handy. Our programs are shorter and simpler. But, once we discovered that it doesn't work correctly in all cases, we shouldn't ignore it. Such imprecisions and ambiguities accumulate, and result in short, but not very understandable programs. What is the correct way out of that? I think that for all such ambiguous, lossy functions need lossless version. For example,



(exists/losless (lambda(x)(not (integer? x))) L)



should return (true nil) if nil is element of L, and (nil) if there is no non-integer elements in L.



Beside that, it is maybe best to keep lossy versions as they are, because these are handy and because of compatibility. Maybe. "Default" version might be either one.



Back to kks's proposal, I think both nth/lossy and nth/lossless have sense.

[kks]

Or, like `lookup`, adding a parameter to `nth` for a "default value" to return in case an index is out of bounds:

Code Select Expand


(nth 5 '(1 2 3) 0)   # => 0


But Kazimir's suggestion is more general, in case we don't know a value that would never exist in the list.

[JeremyDunn]

Thought I would get this thread going again with some more simple things that we might do to jazz things up.



1. I also put my vote in for Kazimir's operators +. and such. They look better and are easier to read.



2. I would like to see some of the math functions overloaded to do common vector operations. For instance, if vec

    is a vector (a list of integers or floats):



    (+ vec) returns (apply + vec)

    (add vec) returns (apply add vec)

    (* vec) returns (apply * vec)

    (mul vec) returns (apply mul vec)

    (pow vec) returns (apply add (map mul vec vec))  ;the sum of squares

    (pow vec n) returns (i1^n + i2^n + .... + iN^n) the sum of the nth power of the elements

    (sqrt vec) returns (sqrt (pow vec))  ;the vector norm

    (div vec) returns the unit vector vec/norm



    The cost of adding these is minimal but the gain for vector math is great in that we can use conventional functions

    instead of a plethora of new ones. Vector expressions will also be greatly simplified.