The Common Lisp (CL) Libraries
Note: This issue almost certainly will be edited to add more points, and might be split into many further issues.
Airship Scheme should be able to access most, if not all, of the base CL language, i.e. the COMMON-LISP
(CL
) package as one or more Scheme libraries. For the most part, that means wrapping it in a similar way to standard-procedures
(#1 (closed)), but most if not all of the macros provided will have to be rewritten from scratch.
There definitely needs to be a way write CL keyword symbols (probably via the :foo
syntax). Being able to work with CL symbol namespaces (i.e. packages) in general could also be a good idea, but then it means that Airship Scheme is not sandboxed, so it should be optional.
This means that Scheme arrays (which are different conceptually from CL arrays), Scheme hash tables, and so on could potentially be implemented in pure Scheme since the foreign CL code would have already been wrapped by the libraries created by this issue. If implemented, these data structures should probably still be exposed to potential CL users of the API.
Some particularly important things to provide include:
-
make-array
,aref
, etc. -
make-hash-table
,gethash
, etc. -
defclass
,defgeneric
,defmethod
, etc. loop
-
setf
(as a generalizedset!
?)
There are several things to note from the above list:
gethash
is a special case because its secondary value is a predicate (and thus needs to be wrapped with nil-to-false
), but its primary value should remain unwrapped. It also has an optional argument (for the default return value if no item is present) that defaults to nil
in CL, but probably should default to #f
from the perspective of Scheme.
Wrapping CLOS should be fairly straightforward, but the boolean
class in CL are not the same as booleans in Scheme. Airship Scheme only has a boolean type, not a boolean class. Dispatching on something that is either #t
or #f
should be possible, though. The CLOS methods themselves will probably be wrapped in regular continuation-passing-style functions.
LOOP
, being a macro, probably should be written from scratch in Scheme. This is by far the most complicated macro in the CL language.
Some functions have an ambiguity between nil
as false and nil
as the return value. One example of this is find
when searching for nil
. These will have to be written in terms of other functions.
There might be a way to wrap macros fairly automatically, such as by calling macro-function
.
Scheme doesn't have a name for the empty list, although some call it null
and some call it nil
. One of the CL packages should export nil
. It would probably be a good idea to also provide the name null
, since Racket uses that name, but conceptually it probably doesn't fit with the CL libraries.
The Scheme procedures should probably support CL-style docstrings and declarations, as well as potentially supporting define-function
-style type declarations.