Partap Davis <[EMAIL PROTECTED]> writes: > I'm new to lisp as well (been lurking), and that's one thing that I've been > wondering about. What exactly is so hard about making a standalone > executable out of lisp source?
Popular operating systems, particularly their executable file formats and function calling conventions, are designed for the needs of their implementation language(s), usually C and/or C++. Lisp environments have different requirements. I guess that the way Lisp environments deal with compiled files (a.k.a. fasl files) and saved images is easier to implement, or more flexible/convenient, than conforming to the operating system's executable formats and calling conventions. > I can understand that if you want to be able to interact with the > source...say for debugging, you need access to the entire environment. But > what if you just want to package a binary for distribution? Besides the code as data relation that has been mentioned, there are advanced programming techniques that rely on the development environment, particularly the compiler. A very good source on these and other techniques is Peter Norvig's book "Paradigms of Artificial Intelligence Programming". Highly recommended, also to novices. As for the debugger, if it is present in the application you deliver, you can debug and fix a running application. That said, many applications don't use environment facilities and their delivered images could be made smaller by means of tools known as "tree shakers" or similar ones, which remove unused subsystems. Commercial Lisp implementations provide tree shakers, but not the free ones. The problem is that writing tree shaker or facilities for creating directly executable files is a systems programming task beyond the capabilities of novices. And experienced programmers are a scarce resource with limited time. > This kind of goes with the other thread about the standard library. > Somebody was mentioning that you would have to include the entire library > whether you used it or not. This is not true for programs written in other > languages. You either only link in the functions that are referenced in the > program, or dynamically link from a shared object file. As I understand things, if the .asd file of an application asserts a dependency on a library, ASDF loads the library into the running Lisp image whether you use it or not. Because of the different function calling and linking conventions, you can rely on the operating system's DLLs only if you access C/C++ libraries--or libraries using the same conventions. If you need a library written in Lisp, you have to load it into the running Lisp image. > Is there something so fundamental to the lisp language that the entire > environment needs to be distributed with a (possible very simple) program? There are a number of reasons, some of which I have tried to outline above. Hope this helps. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
