[alexandria-devel] Alexandria on common-lisp.net
Nikodemus Siivola
nikodemus at random-state.net
Sun Oct 15 16:27:38 UTC 2006
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."
More information about the alexandria-devel
mailing list