I think Alexandria is soon ready to move to next stage: dropping the things that we cannot agree on.
My TODO list before that includes just a few cleanups and documentation tweak (that can be probably best done in parallel with the dropping), and adding three more functions: MAP-COMBINATIONS, -PERMUTATIONS, and -DERANGEMENTS, which I'll merge as soon as I find my MAP-DERANGEMENTS (missing in action, but I know I have it.)
Does anyone else think there is something significant missing?
After we feel that we're as complete as we're likely to get in short order, I propose the following work order:
1. Hash over everything we have, one-by-one:
* Vetos, dropping the things we don't agree on or are feeling unsure about. (Eg. I'm not sure the statistical stuff belongs in Alexandria: is it "good enough" for real statistical work? If not, then we should drop it because people really needing it will just need to shadow it, and others don't care.)
* Checking that the documentation is complete enough.
* Checking that the tests are complete enough.
* Checking that the API is Common Lispy enough: :START & :END arguments, etc.
* 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.
* Checking that we're not defining something that should be a generic function as function.
* Checking that functions have their "obvious" companion functions: REMOVE-FOO, REMOVE-FOO-IF, REMOVE-FOO-IF-NOT, DELETE-FOO, etc.
* Fixing as necessary.
...this is going to take a fair while, so the sooner we get to it the better -- but similarly it doesn't make a real difference if we start a week or few later then sooner.
2. Make the nickname ALEXANDRIA conditional on there not being an ALEXANDRIA.X[.Y] with X greater then 1.
3. Wrap it up as ALEXANDRIA.1.BETA.1, and put it up for public review (month or two.)
If there are comments, attend to them and repeat the beta cycle
5. Rename it as ALEXANDRIA.1, and rest on our laurels.
I futher propose that the stuff we drop goes in BABEL package, which is doesn't make any guarantees about anything -- just a grab-bag of stuff that doesn't fit in Alexandria, and doesn't (yet) have an obvious home elsewhere.
Cheers,
-- Nikodemus
On 11/06/07, Nikodemus Siivola nikodemus@random-state.net wrote:
I futher propose that the stuff we drop goes in BABEL package, which is doesn't make any guarantees about anything -- just a grab-bag of stuff that doesn't fit in Alexandria, and doesn't (yet) have an obvious home elsewhere.
May I ask you guys to pick another name? :-) I just recently more or less released my own BABEL package that is completely unrelated to Alexandria or utilities: http://common-lisp.net/~loliveira/soc07/
Also, may I ask what the consensus (if any) is regarding the idea of defining multiple packages for different sorts of utilities? For example: utilities for macro-writing, sequence utilities (strings, lists, vectors), functional programming utilities, numeric utilities, etc.
Oh, my! IOLib already has such a project, and so does flexi-stream, not to mention each and every CL implementation.
Are you synchronizing with the IOLib author regarding this external-format handling (and other features)? It looks like IOLib is still in active development -- producing enough patches to break my code.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Guns & bullets don't kill people -- blood loss and organ damage kills people.
On 12/06/07, Luís Oliveira luismbo@gmail.com wrote:
On 11/06/07, Nikodemus Siivola nikodemus@random-state.net wrote:
I futher propose that the stuff we drop goes in BABEL package, which is doesn't make any guarantees about anything -- just a grab-bag of stuff that doesn't fit in Alexandria, and doesn't (yet) have an obvious home elsewhere.
May I ask you guys to pick another name? :-) I just recently more or less released my own BABEL package that is completely unrelated to Alexandria or utilities: http://common-lisp.net/~loliveira/soc07/
Also, may I ask what the consensus (if any) is regarding the idea of defining multiple packages for different sorts of utilities? For example: utilities for macro-writing, sequence utilities (strings, lists, vectors), functional programming utilities, numeric utilities, etc.
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).
alexandria-devel@common-lisp.net
-
Attila Lendvai -
Faré -
Luís Oliveira -
Nikodemus Siivola