Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 108
AIList Digest Wednesday, 22 Aug 1984 Volume 2 : Issue 108
Today's Topics:
LISP - Common Lisp & Lisp/VM
----------------------------------------------------------------------
Date: Mon, 20 Aug 1984 15:42 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Subject: Common Lisp
From: weeks%ucbpopuli.CC@Berkeley (Harry Weeks)
Subject: Common Lisp.
... DEC developed Common Lisp at CMU using its money and
apparently many of its own personnel, so they own
the code developed.
DEC's Common Lisp was based on Spice Lisp -- a portable Common Lisp
implementation (written almost entirely in Common Lisp) for personal
workstations. The Spice Lisp code is in the public domain, but the
VAX-specific compiler and runtime code is owned by DEC. They have certainly
made big changes even in the Lisp-level code so that our sources may be very
different today, but most of the work done at CMU was on a portable,
public-domain implementation.
Perq Systems is (or will be) selling Common Lisp for the Perq -- their
implementation IS Spice Lisp, with little or no change. Right now it is
jointly maintained by Perq and CMU. Data General has also announced a Common
Lisp (based on Spice Lisp as well). Symbolics is currently working on a Common
Lisp Compatability Package (CLCP) that is NOT based on Spice Lisp. Because of
the strong similarity of Common Lisp and Zetalisp, such a compatability package
is feasible. I've "ported" two large (source code at least 100K characters)
Common Lisp programs from the Perq (in Spice Lisp) to the 3600 (with CLCP) with
almost no modification.
... There may be a Common Lisp mailing list (Common-Lisp@SU-AI),
but I haven't determined this for certain. I asked to be
put on the list but haven't heard anything back.
That mailing list was used during the design of Common Lisp and has been pretty
quiet lately except for nit-picking issues implementors worry about. There is
currently no "Common-Lisp-Users" mailing list, but one could be created if
Common Lisp was deemed inappropriate material for AIList.
--Skef
------------------------------
Date: 2 Aug 1984 17:06:53-EDT (Thursday)
From: Mark N. Wegman <WEGMAN.YKTVMZ%ibm-sj.csnet@csnet-relay.arpa>
Subject: Lisp/VM - History and Overview
[This is a response to my request for more information.
I have broken the message into two parts. -- KIL]
A SHORT DESCRIPTION OF LISP/VM
______________________________
A complete LISP system, LISP/VM comprises an
interpreter/compiler for its LISP language and an environ-
ment that includes a syntax-oriented editor and run-time
debugger.
History
Created at the IBM Thomas J. Watson Research Center,
Yorktown Heights, New York, LISP/VM grew out of a decade and
a half of experience producing LISP systems. Early LISP de-
velopments at T. J. Watson were derived from the LISP 1.5
developed by John McCarthy of MIT and distributed by SHARE
for the IBM 704. Subsequent modifications and conversions
by Fred Blair, ran on IBM 7090, 7094, 7040 and 7044 comput-
ers. This created and supported a LISP user community at T.
J. Watson that has persisted to this day.
After the introduction of System/360 in the 1960's, Fred
Blair, assisted by James Griesmer, Mark Pivovonsky and
Joseph Harry, produced LISP/360, which inherited much from
the LISP 1.5 tradition. LISP/360 ran in both the batch en-
vironment of OS/360 and the time-sharing environment of
TSS/360 and VM/CMS. The advent of the IBM System/370 and
the limitations of the 18-bit address space led to the cre-
ation in the mid-1970s of LISP/370. In the natural evolu-
tion of a system created in a research environment, LISP/370
diverged in its semantics from both LISP/360 and LISP 1.5.
It was eventually frozen as an IUP (installed user program)
and made available to internal IBM sites and some customers.
In 1978, a new LISP project that would substantially enhance
the capabilities of LISP/370 was started. Cyril Alberga,
Martin Mikelsons, and Mark Wegman were the authors of this
new LISP system, called YKTLISP, for Yorktown LISP. In ad-
dition to being enhanced functionally, YKTLISP was provided
with a sophisticated programming environment so that users
would be encouraged to write maintainable and readable LISP
programs. It has been used extensively within IBM and is
now released publicly as LISP/VM. Contributors to the ref-
erence manual included the system authors, John Sowa, and
Mary Van Deusen.
Many people have participated in discussions and reviews
which have contributed to the quality of LISP/VM. They in-
clude: Marc Auslander, Len Berman, Fred Blair, Chris
Bosman-Clark, Alan Brown, Larry Carter, Ashok Chandra, Ken
Chatfield, Alan Cobham, Walt Daniels, James Davenport, Doug
DeGroot, Cay Dietrich, Pat Goldberg, Jim Griesmer, Se June
Hong, Dick Jenks, Paul Kosinski, Vincent Kruskal, George
Leeman, Victor Miller, Jim Moore, George Radin, J.A.
Robinson, Dick Ryniker, Marshall Schor, John Sowa, Barry
Trager, Jean Voldman, and Karen Woolhouse.
LISP/VM Overview
The LISP/VM Reference Manual describes in detail the facili-
ties and operators available in LISP/VM. The purpose of
this description is to list the major features of LISP/VM
and some of the implementation details to allow the experi-
enced LISP programmer to compare LISP/VM to other LISP im-
plementations.
LISP/VM is an interactive LISP system for use on the IBM
System/370 computer. A program development environment is
provided which supports:
? A structure editor for LISP functions and data which al-
lows the creation and modification of objects from the
file system and from the dynamic store.
? An interactive interpreter which uses the editor to dis-
play the course of program execution.
? An indexed file system allowing access to LISP functions
and data individually and as collections.
? A compiler which will produce either immediately execut-
able functional objects, or relocatable objects in
files.
? Carefully designed compiler and interpreter semantics.
In most practical cases, interpreted and compiled code
are fully interchangeable.
? An error handler which will, under user control, either
return to the command level or enter a primitive command
level from which the state of the computation may be ex-
amined.
? Pattern matching during lambda-binding and assignment.
------------------------------
Date: 2 Aug 1984 17:06:53-EDT (Thursday)
From: Mark N. Wegman <WEGMAN.YKTVMZ%ibm-sj.csnet@csnet-relay.arpa>
Subject: Lisp/VM - Features
LISP/VM Features
? Data types
? Numbers include small integers (up to 26 bits), in-
tegers of arbitrary precision (bignums) and floating
point numbers (7 bit exponent and 56 bit fraction).
? Identifiers include characters and gensyms.
? Pairs (lists or conses)
? Vectors of arbitrary objects, integers, floating
point numbers, characters, or bits (Boolean values).
? Hashtables can hash on pointers or structure.
? Readtables allow prefix and infix character and dis-
patch macros.
? State descriptors capture the control and environ-
ment components of an evaluation in a single object.
? Streams are the interface to data in external files.
? Functions and macros, both interpreted and compiled
are ordinary data objects.
? Funargs combine a function or macro and a state de-
scriptor to provide a form of closure.
? Scope and Extent
? Variable bindings normally have lexical scope.
? Variable bindings that are declared fluid have dy-
namic scope.
? Control points established by CATCH and related con-
structs have dynamic scope.
? Labels (or GO targets) have lexical scope.
? Evaluation rules
? Self-evaluating forms (constants) consist of the
numbers, character vectors, bit vectors and NIL.
? Identifiers (symbols or variables) evaluate to a
current lambda-bound value or to a default value
stored in a non-lambda environment.
Special forms as well as macros and function invocations
are recognized by evaluating the CAR of a compound form.
This feature allows all operators in LISP/VM to be re-
defined by the user in order to modify or extend the se-
mantics of the language.
? The special forms are:
CLOSEDFN FUNCTION PROGN
COND GO QUOTE
EVALQ GVALUE RETURN
EXIT LAMBDA SEQ
F*CODE MLAMBDA SETQ
? Macros are applied to the invoking form and the
value of the macro call is re-evaluated. A macro is
defined by assignment or lambda-binding.
? Functions may have a fixed or variable number of ar-
guments. Functions are defined by assignment or
lambda-binding.
? The bound variable part of functions and macros may
be a pattern that specifies the structure of an ar-
gument. Specified components of an argument may be
bound to distinct variables.
? In addition to all the usual type and numeric predi-
cates, LISP/VM includes three forms of structural equal-
ity:
? EQUAL is the traditional equality test. Atomic ob-
jects are EQUAL if their external forms are identi-
cal. Two composite objects are EQUAL if for any
combination of access operations the corresponding
components are EQUAL.
? UEQUAL test for structural equivalence
(isomorphism).
? UGEQUAL tests for structural equivalence and allows
different gensyms in two objects if their patterns
of occurrence are isomorphic.
? All three equality predicates terminate for all data
objects, including objects with shared and circular
structure.
? Control structure
? Simple sequencing constructs include PROGN, PROG1,
PROG2 and COND.
? SEQ defines a sequential context and a scope for la-
bels and EXIT expressions.
? PROG defines a scope for labels as well as a set of
variables, and a scope for RETURN expressions.
? Iterators include the MACLISP-style DO as well as
most of the INTERLISP iteration constructs.
? Mapping operators include MAP, MAPCAR, MAPCAN, as
well as operators that map over vectors.
? Non-local exits are possible with CATCH, THROW,
THROW-PROTECT, and similar constructs.
? State saving and application allows co-routining,
backtracking and other non-LIFO control models.
? Identifiers (symbols) have a pname and a property list.
There is no function-value cell, since function defi-
nition is assignment.
Characters are not a special case in LISP/VM, they are
simply the identifiers with a one-character pname.
Gensyms are identifiers that are created anew each time
they are read.
? Operations on numbers include all the usual arithmetic
functions and a set of in-line operators for small inte-
ger arithmetic.
? Operations on lists normally terminate or signal an er-
ror when the list is circular.
? Hash tables allow hashing on pointers, structure, or
the contents of character strings.
? Operations on vectors include specialized operations on
character vectors (strings).
? Structured data definitions allow named access to the
components of a data object.
? The compiler can be invoked dynamically to compile from
and/or to the LISP/VM heap or external files. In most
cases, compiled and interpreted definitions are equiv-
alent and interchangeable.
Compilations take place in an environment that may con-
tain alternate definitions for operators. Thus, an op-
erator can have a functional definition in the normal
environment, and a macro definition that emits in-line
code in the compile environment.
? Streams allow parsed or character-oriented data trans-
mission between LISP/VM and the external file system.
? Input/Output
? The PRINT function produces an external form for ev-
ery LISP/VM data object. In addition, shared sub-
structure is revealed by markers in the external
form; these markers are recognized by the READ func-
tion.
? The input syntax is determined by a readtable that
defines a wide variety of character attributes.
? Storage allocation
? There are no fixed allocations of storage within
LISP/VM. The boundaries between heap, stack, com-
piled programs, etc., are adjusted dynamically to
make full use of the available memory.
? Garbage collection is done by a copying algorithm
that takes time proportional to the amount of data
that survives the collection.
? A MACLISP compatibility package allows existing applica-
tions to be compiled for use in the LISP/VM environment
------------------------------
End of AIList Digest
********************
