[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