On Fri, Jun 8, 2012 at 6:38 PM, Steve Graham <jsgrahamus@yahoo.com> wrote:
I'm looking for a lisp/scheme which can:
1) Output C code for the application

That's ok with ECL
2) Can trim unused part (tree shake?) of the compiler/interpreter
which is not needed by the app itself. 

ECL is not a compiler/interpreter. It is a library. Just like your C library. So when you link your application with it, you link it with the Common Lisp library.

The problem is that right now ECL is not yet organized as a C library in the sense that when you link with it, you get all of Common Lisp, not just the bits that your application uses. This is so because the original target was a shared library, which saves memory by being shared by as many components as possible (as it happens with your C library)

What would prevent this link-time optimization is currently the list of symbols that ECL has to build. Common Lisp demands that a number of symbols be bound to the functions that they represent. ECL does not know how many symbols you might use during your application's run and thus it has to bind all symbols and functions that belong to the Common Lisp library: you get all of it.

I would go as far as to argue that what you demand is impossible. The following program apparently uses only two functions, but it has access to the whole Common Lisp library

(loop for form = (read *standard-input* nil nil nil)
   while form
   do (eval form))

Even without the evaluator, things are tricky

(loop for symbol = (read *standard-input* nil nil nil)
   while (and symbol (symbolp symbol))
   do (funcall symbol))

this does not use the interpreter, yet it may invoke any function that is named by the Common Lisp package.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)