[alexandria-devel] Moving to next stage

[Attila Lendvai]

> 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).

-- 
 attila