The New Implementation of n-LISP Last edited: Friday, September 30, 1983 at 11:00 Filed on: {DSK}NLISP.TED Written by: Jim des Rivieres This is a first cut at at specification for the new implementation of the n-LISP family of languages. The goals of the project of are n-fold: 1. To provide implementations of 2-LISP and 3-LISP that are serious enough, and efficient enough, to be put to use by participants in the winter term CSLI research seminar. These implementations will run on D-machines. 2. To serve as a testbed for new variations on the n-LISP theme. It should be possible for project members to modify/adapt the existing source code so as to implement a new dialect very quickly. 3. To serve as the basis of an implementation of 3-LISP that can be distributed to interested researchers who have access to a full LISP system (e.g., ZetaLisp, Franz Lisp, T, PSL, MacLisp) but not necessarily to INTERLISP-D. Existing implementations of 3-LISP satisfy none of these goals; they are all too slow, too machine specific, and not very modular. Goals #1 and #2 take precedence over goal #3. Implementation Modules The implementation modules are as follows: Structural Field Functions that implement the structural field. User Interface Functions that provide convenient editing and file management capabilities. Externalisation and Internalisation Functions that implement theta and theta inverse. Central Processor Functions that implement the processor of the object language. Standard Environment Object libraries that implement the kernel, convenience utilities, debuggers, etc. This is the most natural factoring of concerns, though it will become obvious that there are some nasty interdependencies. User Interface In the interest of portability, the system must not require a fancy raster display and mouse. At the same time, it should be possible to utilize such a device if it is available. In particular, the D-machine implementation can and will be spiffy. We will assume that READ and PRINT are primitives in n-LISP, and that character string manipulation, parsing, editing, etc. are all done outside of n-LISP. Stuctural Field There will be a collection of LISP functions that implement the n-LISP structural field. This is not strictly independent of the central processor since there will be a need for processor-specific representations of commonly occuring structures such as environments and continuations. The structural field module will be written in such a way that adding or deleting new structural field categories and representations is possible. Central Processor To achieve speed, there will be at least one central processor that is compiler-based (though the user will not know this). Of course, the central processor is dialect-specific Dialects to Implement First off, we do a compiler-based non-meta-structural dialect with the following properties: Designated domains: truth-values, numbers, symbols, sequences, and functions. Designators: Variable names, symbol names, numerals, booleans, applications, rails, and closures. Primitives extensionsal functions: FIRST, REST, EMPTY, PREP, SEQEUNCE, +, - , *, /, <, =, NUMBER, SYMBOL. Primitive intensional functions: LAMBDA (l), IF, COND, LET, LETREC, DEFINE, BLOCK. Optional primitives: READ and PRINT (non-meta-structural versions). Higher order: definitely. Tail-recursive processor: of course. Multiple arguments: done through currying? or with sequences. ~~~ End of File ~~~ CLASSICp TIMESROMANCLASSICgCLASSICüCLASSICCLASSIC1CLASSICCLASSIC<CLASSICCLASSICXCLASSIC#CLASSIC=CLASSICCLASSICJCLASSICCLASSICÚCLASSICCLASSICCLASSICGACHACLASSICGACHA|CLASSICCLASSICšCLASSICCLASSICśCLASSICCLASSICĎCLASSICHIPPO+CLASSICžzˇ