Standards

The ANSI Standard

The ANSI Common Lisp standard (X3.226-1994) is a clear, well thought and well written standard. It defines a sufficently large set of functionality that even complex and large projects can be moved easily across systems and implementations. The standard was written in (1986-1994) with the goal of consolidating and homogenizing best practices in an already existing Common Lisp community. The standard is currently under the aegis of INCITS committee J13.

Unfortunately things for which there at the time wasn't sufficent demand, or for which no common consensus of best practices existed, were not standardized. What we seen now is the emergence of new best-practices and (hopefully) their eventual consolidation into standardized interfaces.

The ANSI standard is available online:

• HyperSpec by LispWorks
• Version maintained by Franz Inc

Standard proposals

• Multiprocessing
  • com-metacircles-clim-sys-mp
• OSI Interface
  • fi-hut-tsiivola-osi
• POSIX Interface
  • com-metacircles-posix

Where should things like MOP, CLIM, and Gray / Simple Streams go? They are far more standard then all the implementation specific XYZ-API's, but they aren't really "standard proposals" either... Also, IMHO links to implementation specific API's should also be collected somewhere. Where? -- Nikodemus

I think we should put everything with ambitions to ubiquity in the same list, but indicate on each line what its current state actually is. e.g. "amop (many implementations, including all Lisps whose CLOS derives from PCL. Some disagreement over exact method arguments)", "acl socket interface (Allegro, partial support in many other lisps by means of acl-compat library)" or "com-example-foo (pipedream, not implemented anywhere)"

Guidelines

While these guidelines do not make a standard out of an interface specification, they do greatly enhance the chances of widespread adoption and even eventual standardization.

• General design. An API engineered to the requirements of a specific application does not qualify: the interface has to be designed for general use.
• Legally unencumbered. A specification should be at least freely implementable. Being freely distributable is obviously a bonus, but probably not necessary.
• Maintained. The maintainer of a specification has final authority over it, including future versions. A maintainer can be an individual, organization, or a company.
• Versioned. Unimportant as long as only the initial version exists, but paramount later so that the different versions can be differentiated.

How to add proposals?

• Naming convention. Even if the goal is to provide a canonical interface FOO, it is somewhat presumptuous to hog the namespace with each proposal. Hence use guaranteed unique names like COM-DOMAIN-FOO, COM-METACIRCLES-POSIX, etc.
• Storage. The actual text of the proposal should be hosted elsewhere so that change control is possible, with the page itself containing a URL and comments.