Alexandria is now on clnet, and the initial version is in darcs:

darcs get http://common-lisp.net/project/alexandria/darcs alexandria

gets it.

darcs push <username>@common-lisp.net:/project/alexandria/darcs

is the way to push changes. (Real directory is /project/alexandria/darcs.0, /project/alexandria/darcs and /project/alexandria/public_html/darcs being symlinks.)

For the sake of list archives, here's the project description once again:

Alexandria is a project and a library.

As a project Alexandria's goal is to reduce duplication of effort and improve portability of Common Lisp code according to its own idiosyncratic and rather conservative aesthetic. What this actually means is open to debate, but each project member has a veto on all project activities, so a degree of conservativism is inevitable.

As a library Alexandria is one of the means by which the project strives for its goals. Alexandria is a collection of portable Public Domain utilities that meet the following constraints:

* Utilities, not extensions: Alexandria will not contain conceptual extensions to Common Lisp, instead limiting itself to tools and utilities that fit well within the framework of standard ANSI Common Lisp. Test-frameworks, system definitions, logging facilities, serialization layers, etc. are all outside the scope of Alexandria as a library, though well within the scope of Alexandria as a project.

* Conservative: Alexandria limits itself to what project members consider conservative utilities. Alexandria does not and will not include anaphoric constructs, loop-like binding macros, etc.

* Portable: Alexandria limits itself to portable parts of Common Lisp. Even apparently conservative and usefull functions remain outside the scope of Alexandria if they cannot be implemented portably. Portability is here defined as portable within a conforming implementation: implementation bugs are not considered portability issues.

* Team player: Alexandria will not (initially, at least) subsume or provide functionality for which good-quality special-purpose packages exist, like SPLIT-SEQUENCE. Instead, third party packages such as that may be "blessed".

Is everyone happy with this description as it stands for now?

I'd like to propose a couple of ground rules:

* Repository is fair game. Hack as you will.

* Before release, every member can veto any _new_ feature in the release: it gets deleted from the repo that becomes the release. (Of course, it is better to just hash things out nicely, but in the end, a veto is a veto -- welcome to the consensus, etc.)

* Once a release is made, any future release with packages accessible using the same package names will be backwards compatible modulo bugs and bgufixe. We will not knowingly break backwards compatibility of Alexandria, ever, though we will not be bug-for-bug compatible either. If new interfaces are needed, they get new names, or a new package -- say BANGLADESH. ;-)

Is this ok with everyone?

As for the contents of the repository, I'm pretty happy with the contents I pushed*, but would still add IF-LET, IF-LET*, WHEN-LET, and WHEN-LET*, and possibly cull out the GAUSSIAN-RANDOM, MEAN, MEDIAN, VARIANCE, and STANDARD-DEVIATION.

Cheers,

-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."