Subject: Re: [historical] Invoking a Lisp compiler From: Erik Naggum <erik@naggum.no> Date: 1999/01/23 Newsgroups: comp.lang.lisp Message-ID: <3126088259895935@naggum.no> * "Matthew X. Economou" <xenophon@irtnog.org> | Would it be sensible to have a Lisp compiler that could be invoked | similarly to e.g. CC under UNIX? no, because the results aren't "linked" and "executed" from the command-line, except, of course, in a similar "batch" mode. note, however, that the command-line is really an interpreter and calls out to functions that are loaded from disk every time. usually, this interpreter has some strange syntax for sub-evaluation and has only a few simple control structures, cannot use the value from the functions it has called except through arcane syntax, and usually you have to deal with their "output" through I/O, not actually any values per se. re-using the output of a function may also need a lot of work because it has been optimized for people, not for re-use. I prefer the REPL in Lisp... | EMACS uses the term "Lisp image" when describing the last stage in its | build process. The build process, in this final step, starts up the | EMACS Lisp engine (src/temacs) and loads all of the various editing | functions into memory. It then forces a core dump of this running | system, and the core file is then "undumped" (their terminology) into a | runnable executable (src/emacs). that last past is wrong. the executable is not built from a core dump. by that time, too much is actually lost to be useful in building an executable on most operating systems. instead, the information in memory is written out in a way and an order that causes it to be loaded into memory the same way. basically, the process is that of preparing to make the operating system re-create the conditions that exist in the image at dump time. | Is this (effectively) what "build a new Allegro CL image" means, or does | Allegro (and, I'm assuming, other modern Lisp implementations) do | something more like the typical C or FORTRAN compiler? no, they do basically the same thing: load it into memory, then write memory to disk in a way that causes it to be loaded in the same way. note that a C program doesn't necessarily know what it will look like in memory until actually loaded. there are lots of "loose ends" that the operating system and the dynamic object loader take care of. | The related question is, can one generate DLLs and whatnot with Allegro | (and/or other modern Lisp implementations)? yes. however, "DLL" is a Windows thing. it is as yet not possible for end users to build shared objects or shared libraries, the Unix way. | Can one call DLLs from within Allegro, and does spec say anything about | this? which spec? the documentation for Allegro CL details a foreign interface that I believe is fully capable of using any DLL the system provides. | I'm curious, because every use I've put Lisp to (...) invokes this "self- | containedness" property (...), whereas languages like ADA, Perl, C, | FORTRAN, and Pascal seem to be very good at mixing code (...). Common Lisp implementations are better at this than most other languages -- they have to by virtue of being in a minority. however, Lisp has a much different concept of what constitutes "interface" than C does, and the C calling conventions are sorely lacking in the needs that Lisp has. also, of course, statically typed languages discard type information by execution time, and Lisp keeps it around in the pointers and such. calling out to foreign functions is no big deal, you only need to declare them properly, but that is no news to people from the languages you need to talk to. if the language is any good (and most aren't :), you should be able to generate the interface code in Lisp automatically. however, there is often insufficient information on how the run-time system calls its own functions that it is possible to do this without actually compiling some interface functions and go through an expensive interface that has known properties. | I seem to be having a difficult time picturing such a Lisp compiler | though; all my experience with Lisp has been with interpreted | environments like EMACS, GCL, or Chez Scheme. Emacs and GCL have compilers and you really need them. don't know about Chez Scheme, but from what I have read, it does indeed compile files and all that stuff. how do you picture a C compiler? would it be harder if you could type in C code to an interactive environment and see results immediately? BTW, I think you confuse "interpreted" with "interactive". you really don't know what happens when ypu have typed in an expression. for all you know or care, the system doesn't do (loop (print (eval (read)))), but (loop (print (funcall (compile nil `(lambda () ,(read)))))) #:Erik -- SIGTHTBABW: a signal sent from Unix to its programmers at random intervals to make them remember that There Has To Be A Better Way.