So SLIME puts its FASLs into (now) implementation/os/architecture unique directories. For the Lispbox distro I'm making I'm providing extensions to ASDF to do a similar thing in order to make it easier for folks to play around with multiple Lisp implementations simultaneously.
Now I'm thinking about providing a mechanism to modify the behavior of slime-compile-file so can be made to put FASLs in the same place as the ASDF extensions do. Basically I'm thinking of adding a variable that can contain the name of a root directory that will be analogous to ~/.slime/fasl/ except for user code. If this variable is set slime-compile-file will arrange to pass the appropriate :output-file argument to CL:COMPILE-FILE. The only other wrinkle is that slime-load-file should also be aware of where the FASLs could live. Since the whole way that CL:LOAD checks for a compiled version and then a source version is left to the implementation it seems that I'd have to implement a similar algorithm "by hand" in SWANK:LOAD-FILE. Which might be a good thing because that would cause SLIME to smooth over one more possible subtle difference between impls. So my plan is to implement an algorithm like:
(if (pathname-type file) (cl:load file) (let ((fasl (find-fasl-for-file file)) (source (find-source-for-file file))) (if (and fasl source (> (file-write-date fasl) (file-write-date source))) (cl:load fasl) (cl:load source))))
where FIND-FASL-FOR-FILE knows how to look in the directory where COMPILE-FILE would have put the FASLs and FIND-SOURCE-FOR-FILE will look for a file with a .lisp, .cl, or .lsp extension. (In that order, with the set of extensions to be controlled by an elisp variable.)
Anyone have any big problems with this or see any major flaws in my plan?
-Peter