International Lisp Conference 2009
Lisp: The Next 50 Years
NavigationUser login |
CLtL3: Codifying Modern Common LispCLtL3 Manifesto Common lisp has never been a static language.Originally, Common Lisp was "designed as a description of a family of languages"[1]. The Lisp systems at the time were largely incompatible with one another, and were often internally inconsistent, but shared many common features and saw wide use. Through a grassroots effort, users and developers of these systems were able to agree on a "common dialect to which each implementation makes any necessary extensions[2]". It was deliberately left under-specified in many areas, so that the "various dialects that are super-sets of Common Lisp may serve as laboratories within which to test language extensions[3]". This is the language described in "Common LISP: The Language (first edition)". Once this new dialect was in wide use, many of these language extensions became de facto standards. A desire for stricter standardisation brought about the ANSI effort, during which users and implementors were able to again come to a consensus. This new language was first described in "Common LISP: The Language (second edition)". At that time, it was noted that "moving large bodies of Lisp code from one computer to another is now routine"[4]. The Common Lisp effort was a success. The ANSI effort made a Common Lisp an internationally recognized standard. Once again, many parts of the language were left unspecified to allow for differences in architectures, and for experimentation with language extensions. With the growth of ANSI Common Lisp, the time has again come when it is apparent that many language extensions have become de facto standards and could benefit by being a part of the "Common Lisp". The description of the language has been static since ANSI, but the language itself has not. CLtL3 is another grassroots effort that will attempt to unify widely used language extensions and update some of the core language components. We wish to create a common lisp "standard library" that includes the features modern lisp programmers have deemed necessary. In most cases, various implementations and existing libraries already provide these features, we simply wish to codify and document them in order to promote portability and enable widespread distribution and use of Common Lisp code. Drew Crampsie - drewc at tech.coop [1] _The Common Lisp HyperSpec_ section 1.1.2 http://www.lispworks.com/documentation/HyperSpec/Body/01_ab.htm -------
|
Active forum topicsNew forum topicsSearch |
Deprecating things? Adding implementation requirements?
Do you plan to deprecate things? Common Lisp is enormous, and there are parts of the language that don't seem to be really necessary. It would be bad to just remove them, but maybe deprecating would be nice?
Also, do you have plans to add implementation requirements to the standard? For example, requiring implementations to offer a way to make static memory available (so external programs can use it via FFI).
It depends
What parts of the standard seem unnecessary to you ? I do think that some parts should become deprecated, but only to be replaced by more modern APIs: I'm referring to the current streams and filesystem interface.
Regarding static arrays, I agree that they should be part of the standard.
caaadr, plists?
Well... Some that don't seem to be relevant to me (maybe my view is too partial) are aliases like caaadr & family and plists for symbols. There may be more.
Are these extensions user-definable?
What are the goals of CLtL3?
Do you aim "just" at "standardizing" what's already available as semi-portable libraries that can be done with a layer of user definitions?
Do you aim at standardizing any non-trivial language extensions that one or the other CL already has, but that would require work for other vendors that can't be done with a layer of user definitions?
If you're only interested in the first case -- what more do you bring?
If you're interested in the second case -- what leverage do you have to get it done?
First things First.
Our initial goals involve documenting and distributing a cohesive set of features based on the existing semi-portable libraries. The goal is not to create _the_ standard, but 'a standard'. By keeping the initial scope very small, we hope to actually achieve something useful.
Documenting a set of features and presenting it as a whole has some advantages just by itself. New users will benefit from having a 'known good' set of libraries from which to start, and developers of libraries can achieve a level of portability simply by coding to this community standard. The time and effort that goes into researching and defining this extension of CL will be of great value to any developer who now doesn't have to do it on their own.
Since of lot of these semi-portable libraries are in fact interfaces to non-trivial language extensions, we're into the second case regardless. If enough users want a feature that CLtL3 provides but only implements on certain systems, an implementor may see value in adding that feature. Since we have not yet made any firm decisions on what is and isn't in scope, i can't really say what, if anything, we'll ask of vendors.
Common lisp is growing, but there is no focus or direction in the mythical community. I think CLtL3 is as much a social effort as it is a technical one, and any leverage we acquire will be a result of the people involved, both developers and users. By starting small and focusing on achieving something useful, we hope to attract enough people to make CLtL3 an attractive dialect for lisp implementors, distributors, and users alike.