shen-cl
shen-cl copied to clipboard
Add Support for ASDF, Quicklisp
As mentioned in #25 by @Drainful, we should look at adding support for ASDF and maybe Quicklisp.
The current design of the source code is only suited for building a binary. Many programs (perhaps most programs?) using Shen won't want to be built on a Shen foundation and would rather be build on a native CL foundation that hosts components built with Shen.
I also think having a library distribution that supports all major Common Lisp implementations would be better than the way it's set up now, where the Makefile is generating binaries for every platform. Having it in library form as shen.lisp
and just a single SBCL prebuilt binary would make more sense.
Ideally, one could add Shen to an existing CL project with a Quicklisp command.
I don't think I know enough to attempt this, but I did find an embedding of ISLisp in Common Lisp ( https://github.com/ruricolist/core-lisp ). Perhaps this could be useful for Shen.
I don't know too much about ASDF and QL but before we can do anything with them, some refactoring is needed in order to produce a source distribution of shen-cl as a library, a shen.lisp
or set of .lisp
files.
I did some work to do that on ecl-enhancements when trying to get ECL to work.
I'd like to poke the stick on this. Anyone giving this some love? As it stands, this seems really awkward. I have sbcl now. Do I really need another sbcl binary just to have shen on top?
Wanted to also indicate my support for this change. A quick skim of the src
directory indicates that the actual setup files are fairly well-organized, encapsulating symbols in the :shen
package, so adding in ASDF shouldn't take too much effort.
If I understand correctly the boot.lsp
depends only on the lisp files in the src
directory, and defines the shen-cl.toplevel
function to read and interpret .shen
files. Setting up an ASDF load order for the CL files in the src
directory (i.e. marking each file in the list so ASDF knows which other files it depends on) with boot.lsp
depending on all of them should have the same effect, after which you could ask users to run an init
function (I think ASDF allows just adding a function after a system builds, too, but I'm not sure how that's done) which uses system-relative-pathname
to find the .shen
setup files and then calls shen-cl.toplevel
on them.
Writing a separate interface function for actually defining/calling shen code in a CL file is a bit more work, but Coalton's approach of separate "toplevel" and "non-toplevel" macros with different capabilities could probably work here as well.