tvl-depot/third_party/lisp/alexandria
2020-02-21 13:54:53 +00:00
..
doc
.boring
.gitignore
alexandria-tests.asd
alexandria.asd
arrays.lisp
AUTHORS
binding.lisp
conditions.lisp
control-flow.lisp
default.nix chore: Rename pkgs->depot in all Nix file headers 2020-02-21 13:54:53 +00:00
definitions.lisp
features.lisp
functions.lisp
hash-tables.lisp
io.lisp
LICENCE
lists.lisp
macros.lisp
numbers.lisp
package.lisp
README
sequences.lisp
strings.lisp
symbols.lisp
tests.lisp
types.lisp

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

Homepage:

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

Mailing lists:

  http://lists.common-lisp.net/mailman/listinfo/alexandria-devel
  http://lists.common-lisp.net/mailman/listinfo/alexandria-cvs

Repository:

  git://gitlab.common-lisp.net/alexandria/alexandria.git

Documentation:

  http://common-lisp.net/project/alexandria/draft/alexandria.html

  (To build docs locally: cd doc && make html pdf info)

Patches:

  Patches are always welcome! Please send them to the mailing list as
  attachments, generated by "git format-patch -1".

  Patches should include a commit message that explains what's being
  done and /why/, and when fixing a bug or adding a feature you should
  also include a test-case.

  Be advised though that right now new features are unlikely to be
  accepted until 1.0 is officially out of the door.