Fedora Common Lisp Special Interest Group (CL SIG)
If you're interested in joining as co-lead or regular contributor, please add yourself here:
Common Lisp (CL) is an ANSI-standardized dialect of the Lisp programming languages family, modeled after the Lisp-2 entitled approach of separated namespaces for function names and data variables. There are numerous implementations of CL, most of them being Free Software and available for GNU/Linux, some but not all for Fedora at the time of writing. The usual way to execute CL code is by compiling into the heap and running on top of a CL kernel, making it the fastest dynamic language available. There are also embeddable CL interpreters and CL to C compilers like GNU Common Lisp (GCL) however.
A Special Interest Group (SIG) for Common Lisp would comprise a lobby advocating the use of CL for projects while improving general development support on Fedora by delivering tools and standardized packaging procedures special to CL's nature.
Who the new project would serve?
Common Lisp hackers that Fedora is currently lacking almost completely due to miserable support of the subject, so this SIG will open the community for growth in an area that has almost been ignored so far.
Who will lead the project?
What the goals and scope of the new project would be?
CL hackers will benefit from well-defined, now-incomplete packaging processes for CL libraries and applications, more available and up-to-date CL implementations, faster rates of finishing new package process cycles and the powers of the best distro and the mightiest programming language known to mankind combined. Nowadays being rare, eventually more CL applications will pop up and flourish thanks to our forthcoming efforts.
When can the project be considered a success?
As soon as availability of crucial Common Lisp packages is ensured and the number of CL Fedorans reflects - or even better: outclasses - that of CL programmers in the outside world.
Where the project will lead and where it will fit into the Fedora Project?
`yum list cl-\*' will grow over time, users will switch over realizing what they've missed, GNU emacs will suddenly overthrow vi domination, our system-config-* Python tools will be replaced.. you get the idea. In fact, we've got lobbies for almost all other programming languages and platforms but Common Lisp is still kind of an orphan.
Why does this warrant the creation of a new project within the Fedora Project?
Common Lisp developers are among the happiest but right now they will have a hard time setting up a fully working environment on Fedora, let alone have them create new packages. A SIG will ensure existing packaging guildelines undergo revision and will eventually cover all cases regarding upstream Common Lisp projects. Furthermore, the SIG will form an authoritative and qualified source for answering CL-related questions which is now missing.
How the project will benefit the Fedora Project and the Fedora Community?
Since the SIG will close a gap in the community, it is obviously a worthy addition. Common Lisp is currently in a phase of rejuvenation, i.e. young people are rediscovering the Lisp language family and decide to either go for CL or choose its sibling Scheme or even a successor like Arc. Nevertheless Common Lisp, through its standardization, offers a mature platform that can also be used to write new applications for and from within Fedora.
Plan of Action
Immediate requirements to establish the project
- Creation of the SIG's wiki page
- Finding interested uses
- Setting up a dedicated mailing list
After formation of the project and prior to any actions targeting the packaging of new Common Lisp libraries and applications some crucial amendments to Packaging:Lisp need to be performed by writing drafts to be discussed and approved by the Packaging:Committee:
- The current guideline advocates use of a broken standard (common-lisp-controller) that either needs to be fixed for all CL implementations or replaced altogether
- There are no rules at all for CL-based programs, only implementations and libraries
- Due to Common Lisp's nature, a number of unique questions and issues arise when considering the possibilities of how to package aforementioned programs, e.g. SBCL permits creation of "real" executables by re-bundling the kernel and modified heap image, other implementations must use trampolines
- Most CL programs support different implementations so package naming is an issue; imagine the project `foo' supports ECL and CLISP with unique advantages and disadvantages, do both implementations go into one package so `foo-ecl' and `foo-clisp' are just subpackage? If yes, which is the default implementation to install for `yum install foo'? If not, who or what will prevent naming clashes for another project named `foo'?
Resources and References