If a Common Lisp implementation compiles to native machine code, as
most do, it still needs (as far as I understand it) a platform from
which to run. That is, I can't just compile an application and
distribute the compiled version.
Why is it technically impossible to do so? What is different about
Lisp compilation compared with, say, C or Pascal? (Is it garbage
collection and the other niceties that Lisp provides?)
········@myrealbox.com (Nepheles) wrote in message news:<····························@posting.google.com>...
> If a Common Lisp implementation compiles to native machine code, as
> most do, it still needs (as far as I understand it) a platform from
> which to run. That is, I can't just compile an application and
> distribute the compiled version.
>
> Why is it technically impossible to do so? What is different about
> Lisp compilation compared with, say, C or Pascal? (Is it garbage
> collection and the other niceties that Lisp provides?)
Most systems come with libc, but there's no liblisp. You must also
keep in mind that Lisp is much more dynamic than C or Pascal; even
when the code is compiled, the whole power of the language is still
available at runtime _and can potentially be used_.
Nepheles wrote:
> If a Common Lisp implementation compiles to native machine code, as
> most do, it still needs (as far as I understand it) a platform from
> which to run. That is, I can't just compile an application and
> distribute the compiled version.
well, it's only an illusion that you *can* do this with other
languages. any compiled program (with the possible exception of assembly)
needs a runtime library. what usually happens with C is that after your
source is compiled, the linker combines this output with (part of) the
runtime library. why do you think the basic "Hello World!" program in C
gives you such a large binary? ;-)
btw, with C it's also the case that large parts of the runtime library are
present on the system as dynamical libraries (the .so files in /usr/lib
for instance.)
> Why is it technically impossible to do so?
i don't think it is. don't know why it doesn't happen.
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
(message (Hello 'Joost)
(you :wrote :on '(19 Aug 2004 15:59:12 GMT))
(
JK> any compiled program (with the possible exception of
JK> assembly)
JK> needs a runtime library.
it's possible to write C/C++ program that doesn't need any library - or
maybe just some OS functions for memory allocation, file operations, etc -
but not language-specific library.
in win32, the only required functions are LoadLibrary and GetProcAddress -
everything other can be loaded by program itself.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
On 19 Aug 2004 08:00:51 -0700, ········@myrealbox.com (Nepheles) wrote:
> If a Common Lisp implementation compiles to native machine code, as
> most do, it still needs (as far as I understand it) a platform from
> which to run. That is, I can't just compile an application and
> distribute the compiled version.
>
> Why is it technically impossible to do so? What is different about
> Lisp compilation compared with, say, C or Pascal? (Is it garbage
> collection and the other niceties that Lisp provides?)
It IS possible. The commercial implementations like LispWorks can
deliver "stand-alone" applications - see my freeware app "Regex
Coach"[1] for an example.
The problem is that a CL application usually needs a rather large
runtime library (which is large because the language standard is large
and you can't determine statically which parts of the library you
won't need at runtime). Compare this to a Java application which needs
a JRE to be deployed. To make a "stand-alone" program you have to
bundle and distribute this runtime library with your code.
C programs rely on their runtime libraries (like libc) being installed
at the target platform, they're not really "stand-alone" either.
Cheers,
Edi.
[1] <http://weitz.de/regex-coach/>
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
>>>>> "Edi" == Edi Weitz <········@agharta.de> writes:
Edi> It IS possible. The commercial implementations like LispWorks
Edi> can deliver "stand-alone" applications - see my freeware app
Edi> "Regex Coach"[1] for an example.
Edi> The problem is that a CL application usually needs a rather
Edi> large runtime library (which is large because the language
Edi> standard is large and you can't determine statically which
Edi> parts of the library you won't need at runtime). Compare this
Edi> to a Java application which needs a JRE to be deployed. To
Edi> make a "stand-alone" program you have to bundle and
Edi> distribute this runtime library with your code.
Edi> C programs rely on their runtime libraries (like libc) being
Edi> installed at the target platform, they're not really
Edi> "stand-alone" either.
Hi Edi,
While I'm not the original poster, I am curious. I downloaded the
Linux version of your Regex Coach, to see how much really gets bundled
along with it. It looks like just another executable to the "file"
command, but doesn't like being stripped or compressed with UPX. Also,
it doesn't link to a local shared library for the GUI.
Does it have some parts of Motif compiled statically? The program
appears to try and read parts of itself once it is started. Would you
have any idea what it is doing?
Cheers,
Tim
--
I've had a perfectly wonderful evening. But this wasn't it.
-- Groucho Marx
On Thu, 19 Aug 2004 11:49:17 -0500, Tim Lavoie <········@spamcop.net> wrote:
> While I'm not the original poster, I am curious. I downloaded the
> Linux version of your Regex Coach, to see how much really gets
> bundled along with it. It looks like just another executable to the
> "file" command, but doesn't like being stripped or compressed with
> UPX. Also, it doesn't link to a local shared library for the GUI.
>
> Does it have some parts of Motif compiled statically? The program
> appears to try and read parts of itself once it is started. Would
> you have any idea what it is doing?
No, I'm afraid I haven't. I just used what Lispworks has to
offer. You'll have to ask the folks at Xanalys (they have a very good
mailing list) for details.
Cheers,
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
>>>>> "Edi" == Edi Weitz <········@agharta.de> writes:
I had asked:
>> Does it have some parts of Motif compiled statically? The
>> program appears to try and read parts of itself once it is
>> started. Would you have any idea what it is doing?
Edi> No, I'm afraid I haven't. I just used what Lispworks has to
Edi> offer. You'll have to ask the folks at Xanalys (they have a
Edi> very good mailing list) for details.
OK, thanks. I don't use Lispworks yet really, but wonder now and then
how some of the non-free bits work.
- Tim
>>>>> On Thu, 19 Aug 2004 17:27:01 +0200, Edi Weitz ("Edi") writes:
Edi> On 19 Aug 2004 08:00:51 -0700, ········@myrealbox.com (Nepheles) wrote:
>> If a Common Lisp implementation compiles to native machine code, as
>> most do, it still needs (as far as I understand it) a platform from
>> which to run. That is, I can't just compile an application and
>> distribute the compiled version.
>>
>> Why is it technically impossible to do so? What is different about
>> Lisp compilation compared with, say, C or Pascal? (Is it garbage
>> collection and the other niceties that Lisp provides?)
Edi> It IS possible. The commercial implementations like LispWorks can
Edi> deliver "stand-alone" applications - see my freeware app "Regex
Edi> Coach"[1] for an example.
It's more than just "possible" -- it's entirely normal, and all the
commercial compilers deliver their applications that way. You can
also deliver your program as a shared library (DLL, COM object, etc.)
Edi> The problem is that a CL application usually needs a rather large
Edi> runtime library
It's not "large" compared to the image size or runtime libraries
used by any other programming language on today's modern platforms.
(While it was "large" in 1988, it's "small" today.)
So I would not classify it as a "problem".
I am running a Lisp program that is an e-commerce application,
implementing SQL database access, a web server, and the web
application itself, on my machine right at this moment This is a
debugging version which has not been "shaken" to make it amsller.
It is however, smaller than most of the little decorative and utility
doo-dads (like the westher display or the Process Explorer) that
are running in my Windows system tray. They're written in C/C++.
Edi Weitz schrieb:
> On 19 Aug 2004 08:00:51 -0700, ········@myrealbox.com (Nepheles) wrote:
>>If a Common Lisp implementation compiles to native machine code, as
>>most do, it still needs (as far as I understand it) a platform from
>>which to run. That is, I can't just compile an application and
>>distribute the compiled version.
>>
>>Why is it technically impossible to do so? What is different about
>>Lisp compilation compared with, say, C or Pascal? (Is it garbage
>>collection and the other niceties that Lisp provides?)
>
> It IS possible. The commercial implementations like LispWorks can
> deliver "stand-alone" applications - see my freeware app "Regex
> Coach"[1] for an example.
>
> The problem is that a CL application usually needs a rather large
> runtime library (which is large because the language standard is large
> and you can't determine statically which parts of the library you
> won't need at runtime).
Well it can, if you code tree-shaker-friendly (avoid eval, read
stringified vars, ...), avoid space-costly functions, and if the
tree-shaker (which strips the unneeded library functions from the large
"runtime library") is configured good enough.
I remember the GUI and CLOS version of the layout optimizer application
from the glasgow folks which fits onto a single floppy disc (1.4MB).
tim, what was the name? something with L.
> C programs rely on their runtime libraries (like libc) being installed
> at the target platform, they're not really "stand-alone" either.
C compilers and other simple platforms don't have something like a
"treeshaker", though they CAN very easily determine statically which
parts of the library you won't need at runtime.
perl and python do have, but they have more problems because a lot of
people code dynamically with those languages. (eval, read strings, ...)
re large runtime library:
corman lisp for example compresses its image with gzip. this is tiny and
very easy to deploy.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Reini Urban schrieb:
> C compilers and other simple platforms don't have something like a
> "treeshaker", though they CAN very easily determine statically which
> parts of the library you won't need at runtime.
Just for fairness and unfamiliar users I have to add, that the C linker
adds the needed parts, so this is similar to a tree-shaked lisp lib.
so my argument is bogus.
either use the big shared run-time lib or add it function-by-function
from the static libs.
lisp apps can use either method 1 (shared run-time lib) or the static
method by removing ("shaking") the unneeded parts instead of adding the
needed parts (as the C linker does).
> perl and python do have, but they have more problems because a lot of
> people code dynamically with those languages. (eval, read strings, ...)
>
> re large runtime library:
> corman lisp for example compresses its image with gzip. this is tiny and
> very easy to deploy.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
Nepheles wrote:
> If a Common Lisp implementation compiles to native machine code, as
> most do, it still needs (as far as I understand it) a platform from
> which to run. That is, I can't just compile an application and
> distribute the compiled version.
You can, if you choose the right Common Lisp. In the world of free
Lisps, OpenMCL and ECL can do it (OpenMCL applications have to be at
least two files: the small Lisp kernel and the larger image file that
contains the application). In the commercial world, at least Lispworks,
Allegro, MCL, and Corman Lisp can do it (and Corman can also make
Windows DLLs).
> Why is it technically impossible to do so? What is different about
> Lisp compilation compared with, say, C or Pascal? (Is it garbage
> collection and the other niceties that Lisp provides?)
It isn't technically impossible at all, though the considerations for
doing it from Lisp are a little different from the considerations from,
say, C.
Probably the biggest difference out of the gate is that most development
systems and operating systems ship with libraries and system calls that
are effectively the C runtime; they don't ship with similar Lisp
runtimes, so Lisp compilers have to supply them.
The stuff you have to do to build a standalone Lisp application depends
on the design of your Lisp system, but it does tend to differ a little
from how you would do it in C. For example, one of the most common ways
to build a Lisp application is to build up the various data structures
that make up the application (remember that in Lisp, executable code is
just another data structure) in a memory image, then write that memory
image to disk. When you launch the application, the Lisp kernel reads
the memory image back in and jumps to the start of your main function.
(Incidentally, Smalltalk, Prolog, and ML compilers often use this same
model).
In that case, a standalone application looks pretty much like an
executable that is the Lisp kernel and another file that contains the
memory image (in fact, this is exactly what an OpenMCL application looks
like, for example).
If you want to make an application into a single executable file, you
must jump through more hoops--perhaps you invent a clever use of the ELF
format, for example, to cram the image data into the executable file itself.
Another consideration is that the Common Lisp language has a large
amount of library stuff built into it standard, and there are some
tricky things about trying to leave them out. If your application uses
EVAL or (SETF (SYMBOL-FUNCTION FOO) BAR) or certain other idioms, then
it gets pretty hard to tell whether any particular library interface is
used or not. THere have been sevearl attempts to invent compilation
strategies that strip out unused portions of the library, and none of
them seems to have been successful in the sense of being widely adopted.
That being the case, individual Lisp applications tend to seem a bit
large. Their size doesn't seem to outrageous nowadays, when applications
like Word and Mozilla dwarf the typical Lisp application, but still,
they are often big enough that Lisp programmers tend to start thinking
it might be nice to reuse the Common Lisp runtime for several different
tools rather than making a bunch of separate, individual tools, each of
them six to thirty megabtyes in size.
But once you've decided that it's a good idea to reuse the Lisp runtime
for several tools, you've decided that you're going to install the Lisp
runtime with your application. That's doable, because there are good
free lisps, but then you've come full circle back to developing a lisp
application that delivers the Lisp environment as part of the application.
And finally, it turns out that there is often a good reason to do that
anyway. If your application includes the Lisp environment, then you can
connect to it and debug it and upgrade it in place whenever a customer
wants you to. Paul Graham, for example, talks about fixing bugs in
Viaweb while on the phone with the customers who complained about them,
and NASA's mission control specialists have repaired faulty routines on
spacecraft while they were in the field, because they could connect
remotely to them and get a Lisp prompt, and use it to diagnose and fix
problems.
This last may explain why, although some developers do make Lisps that
can save standalone apps, some don't.
Thanks, mikel. That clears a lot up.
It leaves me with another question, though: How does GC work with all
of this? All languages with GC that I know of are interpreted, or at
least semi-interpreted (Java & friends). With them, there is a parent
process that can garbage collect as necessary (the JVM, or Perl,
Python, Ruby interpreters), acting as a sort of deus ex machina. If
you're executing a standalone Lisp program, how does garbage
collection happen? Is it somehow embedded?
mikel evins <·····@evins.net> wrote in message news:
<·················@newssvr14.news.prodigy.com>...
> Nepheles wrote:
> > If a Common Lisp implementation compiles to native machine code, as
> > most do, it still needs (as far as I understand it) a platform from
> > which to run. That is, I can't just compile an application and
> > distribute the compiled version.
>
> You can, if you choose the right Common Lisp. In the world of free
> Lisps, OpenMCL and ECL can do it (OpenMCL applications have to be at
> least two files: the small Lisp kernel and the larger image file that
> contains the application). In the commercial world, at least Lispworks,
> Allegro, MCL, and Corman Lisp can do it (and Corman can also make
> Windows DLLs).
>
> > Why is it technically impossible to do so? What is different about
> > Lisp compilation compared with, say, C or Pascal? (Is it garbage
> > collection and the other niceties that Lisp provides?)
>
> It isn't technically impossible at all, though the considerations for
> doing it from Lisp are a little different from the considerations from,
> say, C.
>
> Probably the biggest difference out of the gate is that most development
> systems and operating systems ship with libraries and system calls that
> are effectively the C runtime; they don't ship with similar Lisp
> runtimes, so Lisp compilers have to supply them.
>
> The stuff you have to do to build a standalone Lisp application depends
> on the design of your Lisp system, but it does tend to differ a little
> from how you would do it in C. For example, one of the most common ways
> to build a Lisp application is to build up the various data structures
> that make up the application (remember that in Lisp, executable code is
> just another data structure) in a memory image, then write that memory
> image to disk. When you launch the application, the Lisp kernel reads
> the memory image back in and jumps to the start of your main function.
> (Incidentally, Smalltalk, Prolog, and ML compilers often use this same
> model).
>
> In that case, a standalone application looks pretty much like an
> executable that is the Lisp kernel and another file that contains the
> memory image (in fact, this is exactly what an OpenMCL application looks
> like, for example).
>
> If you want to make an application into a single executable file, you
> must jump through more hoops--perhaps you invent a clever use of the ELF
> format, for example, to cram the image data into the executable file itself.
>
> Another consideration is that the Common Lisp language has a large
> amount of library stuff built into it standard, and there are some
> tricky things about trying to leave them out. If your application uses
> EVAL or (SETF (SYMBOL-FUNCTION FOO) BAR) or certain other idioms, then
> it gets pretty hard to tell whether any particular library interface is
> used or not. THere have been sevearl attempts to invent compilation
> strategies that strip out unused portions of the library, and none of
> them seems to have been successful in the sense of being widely adopted.
>
> That being the case, individual Lisp applications tend to seem a bit
> large. Their size doesn't seem to outrageous nowadays, when applications
> like Word and Mozilla dwarf the typical Lisp application, but still,
> they are often big enough that Lisp programmers tend to start thinking
> it might be nice to reuse the Common Lisp runtime for several different
> tools rather than making a bunch of separate, individual tools, each of
> them six to thirty megabtyes in size.
>
> But once you've decided that it's a good idea to reuse the Lisp runtime
> for several tools, you've decided that you're going to install the Lisp
> runtime with your application. That's doable, because there are good
> free lisps, but then you've come full circle back to developing a lisp
> application that delivers the Lisp environment as part of the application.
>
> And finally, it turns out that there is often a good reason to do that
> anyway. If your application includes the Lisp environment, then you can
> connect to it and debug it and upgrade it in place whenever a customer
> wants you to. Paul Graham, for example, talks about fixing bugs in
> Viaweb while on the phone with the customers who complained about them,
> and NASA's mission control specialists have repaired faulty routines on
> spacecraft while they were in the field, because they could connect
> remotely to them and get a Lisp prompt, and use it to diagnose and fix
> problems.
>
> This last may explain why, although some developers do make Lisps that
> can save standalone apps, some don't.
In article <····························@posting.google.com>,
········@myrealbox.com (Nepheles) wrote:
> It leaves me with another question, though: How does GC work with all
> of this? All languages with GC that I know of are interpreted, or at
> least semi-interpreted (Java & friends). With them, there is a parent
> process that can garbage collect as necessary (the JVM, or Perl,
> Python, Ruby interpreters), acting as a sort of deus ex machina. If
> you're executing a standalone Lisp program, how does garbage
> collection happen? Is it somehow embedded?
GC is simply a part of the runtime library that Lisp uses. You can
consider it to be a subroutine that all the memory allocation functions
(e.g. CONS and MAKE-ARRAY) call to ensure that they have enough memory.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Nepheles wrote:
> Thanks, mikel. That clears a lot up.
>
> It leaves me with another question, though: How does GC work with all
> of this? All languages with GC that I know of are interpreted, or at
> least semi-interpreted (Java & friends). With them, there is a parent
> process that can garbage collect as necessary (the JVM, or Perl,
> Python, Ruby interpreters), acting as a sort of deus ex machina. If
> you're executing a standalone Lisp program, how does garbage
> collection happen? Is it somehow embedded?
You're just unfamiliar with language implementations that are both
compiled to native code and also garbage-collected. There are many
examples of such implementations for languages like Lisp, ML, Prolog,
Smalltalk, Dylan, Oberon, and so on. Indeed, compiler/runtime
combination like this have been around for decades.
(Of course, you will also be able to find implementations of these
languages that compile to bytecodes, and other implementations that use
simple interpreters.)
The typical way GC is done is that routines that ask for
dynamically-allocated memory (like CONS, for example) trigger a check to
see if any space is available. If not, the allocator asks for more
space; if necessary, this causes a garbage collection, which is run by
library code that is built into the application.
This picture is oversimplified; nowadays there are very clever
strategies to ensure that GC doesn't take very much of the runtime of a
process, and those strategies can be quite involved. (I think the GC for
Apple's old Dylan implementation simultaneously used just about every GC
strategy that was known at that time. :-))
However, there is nothing about GC that prevents it being built into a
compiled native-code application--indeed, as I say, that has been done
for decades.
On 2004-08-19, mikel evins <·····@evins.net> wrote:
> You're just unfamiliar with language implementations that are both
> compiled to native code and also garbage-collected. There are many
> examples of such implementations for languages like Lisp, ML, Prolog,
> Smalltalk, Dylan, Oberon, and so on. Indeed, compiler/runtime
> combination like this have been around for decades.
Or even C and C++:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
--
--Tim Smith
Nepheles wrote:
> Thanks, mikel. That clears a lot up.
>
> It leaves me with another question, though: How does GC work with all
> of this? All languages with GC that I know of are interpreted, or at
> least semi-interpreted (Java & friends). With them, there is a parent
> process that can garbage collect as necessary (the JVM, or Perl,
> Python, Ruby interpreters), acting as a sort of deus ex machina.
CL, Scheme, Haskell, SML, OCaml, Clean and even Java have
implementations that produce machine code and still use garbage
collection. It doesn't matter how the program is executed as long as it
operates on data that GC can trace. In most such implementations garbage
collection is triggered on allocation, when there is not enough memory
to fulfill allocation request.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
In article <·························@zodiac.mimuw.edu.pl>, Tomasz Zielonka wrote:
> Nepheles wrote:
> > Thanks, mikel. That clears a lot up.
> >
> > It leaves me with another question, though: How does GC work with all
> > of this? All languages with GC that I know of are interpreted, or at
> > least semi-interpreted (Java & friends). With them, there is a parent
> > process that can garbage collect as necessary (the JVM, or Perl,
> > Python, Ruby interpreters), acting as a sort of deus ex machina.
>
> CL, Scheme, Haskell, SML, OCaml, Clean and even Java have
> implementations that produce machine code and still use garbage
> collection. It doesn't matter how the program is executed as long as it
> operates on data that GC can trace. In most such implementations garbage
> collection is triggered on allocation, when there is not enough memory
> to fulfill allocation request.
>
> Best regards,
> Tom
There's even a garbage collector for C. Look up "Boehm's conservative
garbage collector."
--
Eric Daniel
········@myrealbox.com (Nepheles) writes:
> If a Common Lisp implementation compiles to native machine code, as
> most do, it still needs (as far as I understand it) a platform from
> which to run. That is, I can't just compile an application and
> distribute the compiled version.
>
> Why is it technically impossible to do so? What is different about
> Lisp compilation compared with, say, C or Pascal? (Is it garbage
> collection and the other niceties that Lisp provides?)
I did a version of CMUCL that could generate ELF executables. The
executable would contain what currently gets distributed as an
executable loader program and an image or core file. My version would
incorporate these into a single executable file where the core file
was stored in ELF sections.
This scheme ran afoul of portability issues and lack of time on my
part to rewrite it to deal with those issues.
--
Fred Gilham ······@csl.sri.com
"If I'm going to get paged at 3 in the morning, I'd like it to at
least be my fault, and I'd also like a fighting chance of fixing the
problem." -- Tim Moore, arguing for professional open-source tools
Fred Gilham <······@snapdragon.csl.sri.com> wrote in comp.lang.lisp:
>
> I did a version of CMUCL that could generate ELF executables. The
> executable would contain what currently gets distributed as an
> executable loader program and an image or core file. My version would
> incorporate these into a single executable file where the core file
> was stored in ELF sections.
>
Did you eventually solve the problem with Linux's ELF loader? I recall you
were having trouble with it (whereas it worked on FreeBSD). I would be
interested if you did.
Sam
--
All ITS machines now have hardware for a new machine instruction --
DTRT Do The Right Thing.
Please update your programs.
Sam Zoghaib <·····@zep.homedns.orgSPAM> writes:
> Fred Gilham <······@snapdragon.csl.sri.com> wrote in comp.lang.lisp:
> >
> > I did a version of CMUCL that could generate ELF executables. The
> > executable would contain what currently gets distributed as an
> > executable loader program and an image or core file. My version would
> > incorporate these into a single executable file where the core file
> > was stored in ELF sections.
> >
> Did you eventually solve the problem with Linux's ELF loader? I recall you
> were having trouble with it (whereas it worked on FreeBSD). I would be
> interested if you did.
I had a version that would work on some version of Linux. The
principle is actually the same for any ELF system.
My big problem with Linux was that I was unable to rebuild CMUCL
reliably on Linux boxes. I don't recall ever getting that sorted out.
Note that the major stumbling block for the scheme was the need to
stay synchronized with linker script files. These seemed to change
frequently. If you want to see what one looks like, type
"ld --verbose" on a linux system.
--
Fred Gilham ······@csl.sri.com
A gold coin standard transfers monetary policy-making from central
bankers and government officials to the common man, who can walk into
a bank and demand payment for paper or digital currency in gold
coins. This is the ultimate form of democracy, and the Establishment
hates it. -- Gary North
········@myrealbox.com (Nepheles) writes:
> If a Common Lisp implementation compiles to native machine code, as
> most do, it still needs (as far as I understand it) a platform from
> which to run. That is, I can't just compile an application and
> distribute the compiled version.
Take a look at ECL ( http://ecls.sourceforge.net/ and do not get
frightened by this page, it is alive, well and working ) or GCL. They
both descent from the same code base, but have different focuses. Each
of them is able to produce stand-alone executables, much like a C
compiler would do (as both compile to C). The resulting files are also
quite small, as the runtime environment is in a separate shared
library.
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful