Does anyone else think there is something significant missing?
i'm missing some kind of collecting macro, to avoid the way too much used push/nreverse pattern. this macro should preferably use such names that do not conflict with ITERATE.
i've proposed one some time back, but it's not satisfying enough for inclusion as is.
* Vetos, dropping the things we don't agree on or are feeling unsure about. (Eg. I'm not sure
i would like to bring up the possible removal of SANS (again. it's not that i hate it, but it's a broken window in my eyes... :) SANS is a REMOVE-FROM-PLIST which is a much more intuitive name and matches the CL naming convention of REMOVE/DELETE.
on this note, we should/could add a REMOVE-FROM-ALIST and their DELETE-FROM... counterparts.
then we could define setf expanders for them, no idea on their names though. REMOVEF-FROM-PLIST sounds silly, REMOVE-FROM-PLIST! is (unfortunately) not used much in CL and if there were a DELETE-FROM-PLIST! then DELETE-FROM-PLIST would be confusingly suggesting that it has no side effects. hm, seems like i have more questions then answers here...
another one that bothers me is the STARTS-WITH/ENDS-WITH. currently they check for the first and last element of a sequence. unfortunately it can't be clearly made to work so that it can check both for single elements and sequences (because NIL is both of them) unless we agree on something about NIL and document it. but on the other hand, most of the time (this may be subjective) such a STARTS-WITH/ENDS-WITH is needed that works with sequences, so i usually end up shadowing them.
i personally would be ok if they worked so that when called with NIL they would always return T (so NIL would be taken as an empty sequence). and if we added FIRST-ELEMENT/LAST-ELEMENT then people could use them to test if a sequence start and/or ends with NIL as an element.
these are in no way vetoes, it's rather to bring attention to possibly non-intuitive or less useful parts.
* Checking that the API is future-proof enough: not grabbing names that might better serve other purposes, not using &OPTIONAL arguments if we may end up wanting to later add &KEY arguments, etc.
i agree. clarity first, speed second (by using annotations and/or improving the compiler).