SBCL compilation

design process:
HEY LET'S JUST SHOVE EVERYTHING INTO A SINGLE EXECUTABLE!

LOL LOOK AT ALL OF THOSE 40 MB FACTORIAL PROGRAMS

Its actually an int"derp"reter packaged inside the program, just like python .exe

SBCL is a Lisp-Machine emulator. A QEMU, together with Windows, will take much more than 40 MB.

To be fair, any program that uses an eval function will need to have an interpreter bundled with in its executable, or dynamically link with a library that contains the interpreter. But if the program happens to never call eval, then that could be optimized out of the picture. But then that is assuming the developers could actually write a compiler that would translate the high level program to machine code.

Are there a way to load FASL from inside a zip archive, without unpacking into separate file? I want to simulate a Smalltalk-like system with JIT, so I store closures as fasl into a zip image. How do I load them back?

http://jsnell.iki.fi/tmp/shake.lisp

>>6
Your code looks like it is a part of SBCL implementation. Doubt it's very protable even across SBCL versions.

>>7
That code isn't mine.

>>1
Tree-shake it. Not like most other lisps are much smaller, it's always 8-40MB, depending on what you use and options used.
Major reductions in size should be obtainable if you don't include the compiler and interpreter.
>>2
No, SBCL compiles to native code, but an interpreter and a compiler is included in the code as SBCL doesn't tree-shake (you have to do this, if you want smaller files).