Champion

Ian Eslick

Volunteers

• Chris Dean
• Peter Seibel

Proposal

• Pull together a repository of common lisp utilities under an MIT or BSD style license (no restrictions) to try to enable the world of asdf-installable packages to come to depend on a single common library and so that newcomers will have a body of existing code they can exploit to save time and effort. Start by reviewing common libraries and functions (from Genera, PCL, Norvig's book, Graham's books; as well as arnesi, kmrcl, clocc, etc) and figuring out how to organize them into a simple namespace.
• Properly document all of these functions, potentially with pointers to Common Lisp Cookbook entries where they are used or other documentation (special syntax in the documentation strings?).
• Provide a web interface to the utilities that allows people to search for functions based on what they want to do with them. I can add some NLP magic to this if we can properly stylize the way the documentation strings are written.
• Depending on how the project goes, an active set of developers could be enabled to upload code directly as they find they need certain functions. Other people can post code on a site for community review, categorization and inclusion.

Tasks

• Create an asdf DARCS repository on common-lisp.net
• Settle on a licensing policy (MIT/BSD or also allow LLGPL?)
• Resolve license issues with CLOCC?
• Get permission from authors of various packages & books to incorporate their code under the license policy.
• Create an initial namespace
• Populate with the most common utilities, especially those in books people use (PCL, Onlisp, PAPAI, etc)

Notes and Comments

To kick off a discussion, I thought we might organize code into two tiers. The first includes common utilities that are used all the time - control constructs (aif, if*), list manipulation (group), macro construction (with-gensyms), system maintenance (defun-exported) and typically consist of one or two standalone functions. The second tier would include: small DSL's like Henry Baker's meta, CLOCC's port, or domain specific libraries such as statistics functions, etc. The second tier should probably be their own asdf packages that are only loaded by systems that need them but exist in the utils name space. The bottom tier are always loaded but are separated into separate package name spaces to avoid cluttering the name space of a package that imports utils.
- Ian Eslick

Can anyone think of a good name for the resulting library?
- Chris Dean

We'll need a test framework just to test the library itself.
- Chris Dean

Namespace

This is a working set of ideas, please feel free to edit, comment or modify this section. A simple namespace using the dot notation. Utils is often used by people locally and we don't want to screw up existing environments. Some possible root package names with votes in parens after the name: cl-utils, stdutil (1), stdlib, extlib, common-utils, common-tools, cl-tools.

For secondary categories I'm thinking of anything I use all the time or can expect to find easily with any other language I use. My proposal for secondary categories include:

• empty - stdutil should include a set of very, very common functions. This might be confusing, however and we could require that everything get put into one second level category.
  • control constructs: if*, aif, awhen
  • macro helpers: with-gensyms, normalize-symbols
  • list operations: group, flatten
  • interactive operations
• package - defun-exported and other package definition oriented things
• list - list oriented utilities
• sequence - list & vector oriented utilities
• macro - extended set of utilities used to create macros
• control - various and more obscure control constructs and utilities for constructing them
• arrays - array-oriented utilities
• string - string oriented utilities
• hashtable - hashtable oriented utilities
• collections - A standard set of collection classes? tables, queues, rings, Btrees, etc. Perhaps with a generic function i/f? There are a number of partial systems out there already...
• clos - utilities oriented around clos; helping define, inspect, etc.
• mop - see if we can get Pascal to let us package up closer-to-mop for a lisp independant mop (also export :closer for legacy)
• os - the equivalent or existing "port" package, also provided under :port package name for legacy (also called lisp for a lisp portability package)
• io - octet-stream, other stream helpers, etc
• threads - at some point we'll want to commit to a standard threading package; I belive there's another gardening project on this

Some other functions we might want to include: binary data handling, various simple DSLs for parsing (like meta), state machines, a debugging/logging subsystem, debugging aids, cl-ppcre, xml & xml-rpc. Provide common mathematics, simple list-based matchers, . Anyway, not to be overly ambitious here but just throwing out ideas to help establish the categories within the potential scope of the project.

Explicitely not including test frameworks, documentation frameworks, web anything, ffi, parallel frameworks, persistence solutions, serialization solutions (other than read/write).

Ground rules for adding to the library

• Every exported symbol must be documented
• Every symbol must be part of a consistent naming convention
• Every module must have unit tests

---

Categories

Gardeners Projects