No description
95aeb2ebae
git-subtree-dir: third_party/lisp/alexandria git-subtree-split: fc2a2f5c34147bb4e3e4a350b04220de0263710f |
||
---|---|---|
doc | ||
.boring | ||
.gitignore | ||
alexandria-tests.asd | ||
alexandria.asd | ||
arrays.lisp | ||
AUTHORS | ||
binding.lisp | ||
conditions.lisp | ||
control-flow.lisp | ||
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.