ZetaLisp
ZetaLisp (also known as Lisp Machine Lisp) is a historic Lisp dialect that was mainly used on Lisp Machines.

ZetaLisp is mostly descended from MACLISP. ZetaLisp is documented in the Lisp Machine Manual.

For information about running ZetaLisp on modern computers, see the Lisp Machine emulator information at http://www.unlambda.com/.

Following notes come from source code of LMI K-Machine:

What is ZETALISP?

  1. ZETALISP consists of a set of EXPLICIT PRIMITIVES, UTILITY FUNCTIONS, CONSTANTS, VARIABLES, and TYPES and a specification of the behavior of these functions under certain circumstances.
  2. ZETALISP is complete in that all of the primitives which ZETALISP provides are specified (in the microcode).  For example, the SETF macro causes (SETF (AREF <array> <index>) <new-value>) to change the contents of the array.  Because SETF expands into lisp code that modifies the array, there must be a primitive that can mutate the array.  ZETALISP provides ASET.
  3. ZETALISP is not overspecified, every part of ZETALISP is there for a purpose (albeit not always a good or even useful one).
  4. ZETALISP is defined by the environment running on the LISP machine.
Our problem is that we have 10 megabytes of source in ZETALISP.  We cannot just throw it away.  Our second problem is that some of ZETALISP will not run on the K processor.  Please note that there is the danger that Common LISP will adopt something that cannot run on the K.  There is nothing to be done about that, but there may be some clout we could have if the K becomes popular.

We can divide ZETALISP into several classes of functions, constants, variables and types.
  1. Common LISP compatible:  Where ZETALISP and Common LISP behave identically. Code that is Common LISP compatible does not need any modification.
  2. Common LISP orthogonal:  ZETALISP utilities that would run equally well under Common LISP.  Extra ZETALISP features.
  3. Common LISP superset:  Where Common LISP specifies that "it is an error" to do some particular thing, ZETALISP allows such a thing. Example "It is an error if the array specified as the :displaced-to argument does not have th esame :element-type as the array being created." ZETALISP allows that and "does the right thing" (which, actually, it shouldn't as anyone using this kind of bagbiter is a loser anyway.)
  4. Common LISP incompatible:  ZETALISP does something completely different.
  5. K-machine incompatible:  Features that cannot work on the K.
What do we want to offer to customers?
  1. A full Common LISP environment including the LISP, USER, KEYWORD, and SYSTEM package.  The LISP package is to include all symbols mentioned by Common LISP and all functions are to work as specified in Common LISP.  Any strict Common LISP program should run in this package.
  2. A Common LISP extension package.  These are to be functions that will be written in Common LISP and will be supported indefinitely.  The sources should be available to the user and the user's code should remain portable if he brings the sources over also.
  3. An object-oriented paradigm, probably Common LOOPS.
  4. A ZETALISP compatability package.  These are to be functions that will be written in Common LISP, but perhaps not supported indefinitely. Portable code should be able to be written using these sources, but it should be discouraged.
  5. An EMACS editor, a compiler, an inspector, a debugger, an interpreter (evaluator), job control, and a garbage collector.
  6. A standard window system, when a standard is available.
What do we not want to offer to customers?
  1. Any feature that we are not willing to support until the end of the world. Note that any feature that we add is likely to be used and will cost manpower to maintain.  We may also have compatability problems across systems when we finally abandon the K and move on to better things.
  2. The internal system code.  This is not so much for "security purposes" but to protect ourselves from the customers who won't listen to "don't use this feature" warnings.  It may be true that we treat our customers like children, but unhappy customers generate less income than bug reports and pull down valuable programmers.  I would rather piss off a thousand RMS's than one MCC.