[Ecls-list] Creating C Routine
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Sat Jun 9 16:55:15 UTC 2012
On Fri, Jun 8, 2012 at 6:38 PM, Steve Graham <jsgrahamus at 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)
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel