Common Lisp Open Library

Status

This is preliminary. I don't know if I will ever get serious about it.

Overview

The idea of the Common Lisp Open Library (CLOL) is to provide a set of useful, basic packages that are used by a large number of Lisp programmers.

As it stands now, there isn't a lot of code sharing among Lisp programmers. The Open Library is an effort to create a semi-standard set of libraries, similar to the standard set of libraries available to Python. It will be one central point where code will be freely shared.

Manifesto

Why another library? As it stands now, the libraries that people write are done in an independent and non cohesive way. This isn't bad. Freedom is good. But it is hard, especially for the young and inexperienced.

These libraries are not going to be the final solution. They are only going to be a helping hand up to those Lisp beginners who want to become productive in Lisp quickly. Perhaps some of the packages in the library will become part of the Common Lisp standard. Perhaps not.

If something is wrong with these libraries, if they smell bad or if they do the wrong thing, then you are invited to fix it so that we may all enjoy them together.

These libraries will focus on providing the kinds of features that will help people write good code quickly and easily. If it makes the task of coding in Lisp easier or more efficient or less complicated, it will be added.

Versioning and Backwards Compatibility

The library will be released with version numbers such as X.Y.Z.

The X version increments when a fundamental change is made to the entire library. This would be something like a new vision, a reorganization of several packages, or a complete rewrite of a core package. This will be very rare, of course.

The Y version increments when a new package is added or when the interface of any exported symbol changes. This means that your code will always be compatible with the same X.Y version of the library, as long as you are using exported symbols and not interned symbols.

The Z version increments when something else changes.

As a new X.Y.Z version becomes available, there will always be a release cycle. This is marked by first packaging the software into a beta candidate. During this process, alpha releases may be made, but may not be. When the version is fully assembled, and all the major features are mostly agreed upon, then beta releases will be made. These will be tested and may be changed significantly. When the bugs are worked out, then the release candidate will be put forward. These are the final versions before the release.

Source Code

Right now, I am using git to manage the code. This focuses on a highly decentralized method of development. If you want to access the source code, you can use the following URL: [...]

License

The library is licensed under the LGPL.

Copyright

Right now, the copyright is owned by the respective owners of the code, but it is licensed by the LGPL. I should probably have contributors assign their copyrights to me to ensure that if we need some kind of managing corporation, it can be formed easily without having to track down a bunch of people.

Road Map

• Basic Types
  • /hash -- Helper functions for hashes.
  • /range -- Basic range functionality.
  • /iterator -- Simple iterators, much like what Haskell has.
• Working with Strings
  • /pprint -- Pretty printer.
• Operating System Tasks
• Networking (TCP, UDP, socket server, as well as something like asyncore and asynchat.)
• Network Protocols (SMTP, HTTP, IRC, etc...)
• GUI (Tk, ...)
• ... suggestions welcome ...