Subject: Re: [historical] Invoking a Lisp compiler
From: Erik Naggum <>
Date: 1999/01/23
Newsgroups: comp.lang.lisp
Message-ID: <>

* "Matthew X. Economou" <>
| 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))))))

  SIGTHTBABW: a signal sent from Unix to its programmers at random
  intervals to make them remember that There Has To Be A Better Way.