I'm looking for a lisp/scheme which can:
1) Output C code for the application
2) Can trim unused part (tree shake?) of the compiler/interpreter
which is not needed by the app itself.
I know Gambit-C can do something similar, but it seems a manual
process where the user specifies which parts of the kernel to keep.
I am a newbie and doubt I have such knowledge.
On Fri, Jun 8, 2012 at 6:38 PM, Steve Graham <jsgrahamus@...> 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)
From: David Brown <lisp@da...> - 2012-06-09 19:41:29
On Sat, Jun 09, 2012 at 06:55:15PM +0200, Juan Jose Garcia-Ripoll wrote:
>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
The tree shakers usually have some type of configuration that allows
the developer to specify what is needed (since that isn't determinable
from the code directly). They usually have various options, from
eliminating symbol names entirely, to giving a list of symbols from
common-lisp that the application expects to need, to pulling in all of
They're usually a good bit of work to implement, and kind of a major
feature of the implementations that have them.