Quicklisp Integration ("Quickscheme")
After #16 provides support for ASDF, the next logical step is interfacing with Quicklisp to allow Scheme code to wrap and use Common Lisp libraries, similar to how the Airship Scheme core is implemented. As a working title, call it "Quickscheme" for now. There are also portable Scheme package repositories. Integration with these are a completely different task and thus belong in other issues.
All third party libraries bring up the issue of structure. At the moment, library paths are determined as subpaths from airship-scheme
, e.g. (scheme base)
as airship-scheme/scheme/base.sld
, but this cannot apply to third party libraries. As mentioned in #12, the Scheme convention of (foo bar)
probably should be equivalent to the ASDF convention of foo/bar
, but CL libraries don't consistently use this.
Airship Scheme already uses some Quicklisp libraries and they probably shouldn't be wrapped twice. Perhaps they should become built-ins like the Common Lisp libraries (#15). Some, like bordeaux-threads
and alexandria
, might as well be treated as core parts of CL. Others, like zr-utils
(not currently in Quicklisp), should probably still be treated as a distinct library.
Some Quicklisp libraries might do fancy things with macros and/or reader macros that are too incompatible.
Some useful libraries might be outside of Quicklisp (but could exist in ~/quicklisp/local-projects/
).
If Airship Scheme is being embedded in a Common Lisp application, then the application might want to restrict scripts from accessing Quicklisp. In fact, Quicklisp might not even be available at all in these situations.
Another thing to consider is how to wrap things. If it requires files containing definitions like define-scheme-procedure
, then there needs to be a way to download a current version of this (assuming the CL library doesn't provide it). Otherwise, Airship Scheme needs a separate way to interface with CL. It probably cannot be done entirely automatically because of ambiguity between whether nil
or #f
is intended by CL:NIL
.
The reverse is probably also needed, i.e. Scheme libraries on Quicklisp. This leads to an issue of rules: are libraries allowed on Quicklisp that aren't even written in Common Lisp or is an independent Quicklisp repository necessary? Should all Scheme libraries provide a Common Lisp API to avoid this problem? What about purely syntactic libraries that are of no use in CL, or call/cc
libraries that can't really work in CL?
Finally, the Quicklisp integration presents an excellent pun opportunity in the future. Users could be told to get "Rich Quickscheme", or there could be a git-enriched version called "Git-Rich Quickscheme" (as a fork of Ultralisp). Puns are very important.
Update: As mentioned by jmercouris on Freenode IRC's #lisp
, repositories of Quicklisp software are called "dists" and there is at least one library for generating them. This might be the simplest solution for a "Quickscheme".