ZetaLisp

ZetaLisp is a Lisp dialect mainly used on Lisp Machines, it's considered a even bigger Language than Common Lisp.

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

What is Common Lisp?

Common LISP consists of a set of EXPLICIT PRIMITIVES, IMPLICIT PRIMITIVES, UTILITY FUNCTIONS, CONSTANTS, VARIABLES, and TYPES and a specification of the behavior of these functions under certain circumstances.

An example of an explicit primitive is CAR.
An example of a utility function is MEMBER.
An example of a constant is MOST-POSITIVE-FIXNUM.
An example of a variable is *PRINT-PRETTY*.
An example of a type is SYMBOL.

Common LISP is incomplete in that some of the primitives which Common LISP provides are not specified. For example, the SETF macro causes (SETF (AREF ) ) 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. Common LISP does not specify a primitive that can modify an array.
Common LISP is partially overspecified. There are vestigal parts of things left hanging in Common LISP. An example is the optional ENV argument to macroexpand. It is there, but there is no way to examine, mutate, create or do anything with it. Another example is MOST-POSITIVE-FIXNUM. Since all Common LISP integer operators deal with FIXNUMs or BIGNUMs, there should be no reason for the user to need this constant. In addition, there is no function he can call that will materially change the behavior of the machine if this number is passed as an argument. What is it for?
Several functions in Common LISP do not specify what happens under boundary conditions. What happens if LENGTH is called on a circular list?
Common LISP is vague. *PRINT-PRETTY* specifies that the printer is to "insert extra whitespace where apropriate to make the expression more readable".

Basically, Common LISP is obviously an incomplete kludge. The danger here is if it turns into a complete kludge. It is clear that some parts of Common LISP were to be specified at a later date. Maybe macroenvironments will be implemented, for example. The implementor has several choices to make as regards the unspecified parts of Common LISP. Common LISP may in the future specify these things, and if the implementor has guessed wrong, he loses.

What is ZETALISP?

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.
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 ) ) 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.
ZETALISP is not overspecified, every part of ZETALISP is there for a purpose (albeit not always a good or even useful one).
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.

Common LISP compatible: Where ZETALISP and Common LISP behave identically. Code that is Common LISP compatible does not need any modification.
Common LISP orthogonal: ZETALISP utilities that would run equally well under Common LISP. Extra ZETALISP features.
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.)
Common LISP incompatible: ZETALISP does something completely different.
K-machine incompatible: Features that cannot work on the K.

What do we want to offer to customers?

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.
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.
An object-oriented paradigm, probably Common LOOPS.
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.
An EMACS editor, a compiler, an inspector, a debugger, an interpreter (evaluator), job control, and a garbage collector.
A standard window system, when a standard is available.

What do we not want to offer to customers?

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.
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.

This page is presently Common Lisp implementation: please add appropriate topic markers and remove this text

This page is linked from: Zeta-C

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively