Copy Link
Add to Bookmark
Report
AIList Digest Volume 4 Issue 117
AIList Digest Friday, 9 May 1986 Volume 4 : Issue 117
Today's Topics:
AI Tools - Common Lisp Support for Object-Oriented Programming
----------------------------------------------------------------------
Date: 29 Apr 86 11:26:00 PDT
From: "Jennings, Richard" <jennings@lll-icdc.ARPA>
Reply-to: "Jennings, Richard" <jennings@lll-icdc.ARPA>
Subject: Summary: Common Lisp Support for Object Oriented Programming
I posted a query to AILIST concerning available PUBLIC DOMAIN object
oriented support within the Common Lisp programming environment. This
article should serve to disseminate to the network the information I
obtained. FIRST, my original query is reproduced. SECOND, is a summary of
specific references (network addresses) to whom follow-up questions should
be directed. THIRD is an edited summary of some of the responses I
recieved. Finally, I am providing some further information about the
project I am supporting, because of numerous requests.
I. Original Query:
Article 469 of mod.ai:
Subject: Object Oriented Support For Common Lisp
Date: 24 Apr 86 06:46:40 GMT
I am working on a project trying to couple a good programming
environment exploiting object oriented paradigms to a grid of INMOS
Transputers. Rather than build up everything from the OCCAM
development system, I would like to use the VAX LISP (a variant of
Common Lisp) environment augmented with a public domain (preferably)
object oriented package as a model for the system I intend to build
for the Transputers.
1) I would like pointers to environments which are compatible (sit on
top of) VAX LISP which directly support object oriented programming;
2) notes from those who may be working on (or interested in) such
projects; and
3) responses sent directly to me since I do not have regular access to
AILIST. I will summarize.
II. Summary of Network Information Sources
CORBIT => desmedt%hnykun52.BITNET@wisc.wisc.edu
PD Common Lisp => fahlman@c.cs.cmu.edu
Common Loops => gregor.pa@xerox.com
REX => wells@sri-ai.arpa
NCUBE => duke@mitre.arpa
VAXLisp Flavors => beer%case.CSNET@csnet-relay.arpa
III. Summary of Responses
===============================================================================
[1] Subject: OOPS for Lisp and VAXLISP on Transputer
Return-Path: <Fischer.pa@Xerox.COM>
The lisp sources that VAXLISP was built from are public domain ... These are
the Spice Lisp sources from CMU, contact Fahlman@c.cs.cmu.edu.
There are a few object programming standards emerging within the Common
Lisp community. A partial list is: Xerox CommonLOOPS, New Flavors
(Symbolics), Common Objects (HP Labs), and Object Lisp (LMI).
Group Information Contact
CommonLOOPS Gregor.pa@Xerox.Com
New Flavors Moon@SRC.Symbolics.Com
Common Objects Snyder@HPLabs.Com
Object Lisp ? [anybody know about this? -rkj]
[A message to Scott Fahlman obtained:]
Subject: Public Domain VAX LISP
Return-Path: <FAHLMAN@C.CS.CMU.EDU>
What we could give you is Spice Lisp, developed here for the Perq computers and
in the public domain. This is essentially Common Lisp written in Common Lisp
and a Common Lisp compiler, written in Common Lisp, that produces a special
Lisp-oriented byte code that is executed by custom microcode on the Perq. We
also have an Emacs-like text editor written in Common Lisp, and some assorted
utilities and demos. There's a design document describing the internal
organization and defining the byte codes.
What various manufacturers, including DEC, have done is to take our sources and
modify the code generation modules of the compiler to produce native code for
their machine. Most of the byte codes turn into a few native-code instructions
on something like a Vax. The more complex ones turn into quick jumps to
hand-coded subroutines, probably written in assembler: bignum arithmetic,
building and taking apart stack frames, GC, lowest-level operating system
interfaces, and so on.
To build a system, you then run the modified compiler on some system that
already has a Common Lisp, compile our whole body of Lisp code, link in the
hand-coded stuff, and if you've done it all right the Lisp comes up in its full
glory, ready to go. It is possible to get a reasonably fast implementation by
this route, though it takes a good deal of thought and tuning to get the data
formats and calling conventions just right.
Veterans of our implementation effort have done this port to a new architecture
in as little as six man-months ... under optimal conditions. A more realistic
time scale for someone starting from scratch on this would be two good wizards
working six months to get something turning over, and another six months or a
year to get the thing up to full speed and product quality. That's for a
straightforward port ... All of the sources add up to 3 or 4 megabytes...
Since you ask about Vaxlisp, it is the result of the same process described
above, and the work was done here at CMU by DEC employess and by me as a
consultant to DEC. The result is owned by DEC and we can't give it to anyone.
-- Scott
===============================================================================
[2] Subject: CORBIT - an object-oriented programming system
Return-Path: <DESMEDT%HNYKUN52.BITNET@wiscvm.wisc.edu>
You may be interested in CORBIT, an object-oriented programming
environment in Common LISP. I will summarize some aspects of the system.
1. History
CORBIT stands for ORBIT in Common LISP. ORBIT was originally written in
MACLISP by Luc Steels at Schlumberger, then rewritten in FRANZ LISP by
Steels and myself, and finally rewritten in NIL Common LISP by myself at
the University of Nijmegen. ORBIT and CORBIT are now used by a small
number of people in the scientific community and are not commercially
available.
2. What is it?
CORBIT is basically an object-oriented extension of LISP. As such, it
ranks among the Flavors package, Common Loops, etcetera. However, it has
some features which make it stand out from the pack:
- Inheritance is done by delegation rather than by copying down. See
recent articles by Henry Lieberman for a discussion of this distinction.
- Partly as a result of this, the system is much more flexible than most
similar systems with respect to adding and changing information. For
example, one can create instances of objects that don't exist yet.
- There is no formal distinction between 'classes' and 'instances'.
Everything is an 'object'. The only hard distinction is between named
objects and anonymous objects.
- Invocation of an object-oriented operation is performed by plain LISP
function calling, not by message passing (as done in Common Loops).
- There is no distinction between so-called 'instance variables' and
'methods'. Everything is accessed by means of a function.
- There are a number of fancy extra features such as 'if-needed' methods
and backpointers.
3. Applications
Applications have been very much of a pre-prototypical nature so far.
ORBIT has been used for VLSI-design, representation of geological
knowledge, implementation of a (rather primitive) window system, natural
language generation, and a small office environment.
4. Accessibility
The only two papers related to CORBIT are really related to its
predecessor ORBIT: (1) a manual (slightly outdated, published as an
internal report, now out of print but still available on electronic
medium) and (2) a forthcoming article which compares the ORBIT and
Flavors systems.
Koenraad De Smedt Bitnet address: DESMEDT@HNYKUN52
University of Nijmegen
Psychological Lab
Montessorilaan 3
6525 HR Nijmegen
The Netherlands
[Koenraad sent me a copy of the report, ~43p, which I am now reading -rkj]
===============================================================================
[3] Subject: Portable CommonLoops
Return-Path: <Gregor.pa@Xerox.COM>
Portable CommonLoops (PCL) is an implementation of CommonLoops written entirely
in CommonLisp. Currently, PCL runs in the following Common Lisps:
Xerox
Symbolics
Lucid
Spice
TI
VAXLisp
PCL is available to Arpanet sites by anonymous FTP (username "anonymous",
password "anonymous"). For the time being we are restricting distribution to
sites which can FTP PCL for themselves because we want to make it possible to
have frequent new releases of PCL.
The files are stored on PARCVAX.xerox.com. You can copy them using
anonymous FTP. There are several directories which are of interest:
/pub/pcl/ PCL sources and (some) documentation
These following directories contain binary files for some
of the machines PCL runs on, there will be more machine
specific directories once we are set up to get more binaries.
/pub/pcl/3600/ binaries for the 3600 (rel 6.1)
/pub/pcl/lucid/sun/ binaries for Lucid Lisp on the SUN (rel 1.0)
/pub/pcl/ti/ binaries for the TI Explorer
...
In the directory /pub/pcl/ the files:
notes.tx contains notes about the current state of PCL, and some
instructions for installing PCL at your site. You should
read this file whenever you get a new version of PCL.
manual.tx is a VERY ROUGH [very rough -rkj] pass at "documentation".
I hope there will be some better documentation soon.
Send mailing list requests or other administrative stuff to:
CommonLoops-Coordinator@Xerox.com
[I obtained the VAXLisp sources, and am in the process of bringing them
up. They seem to be written for VAXLisp 2.0 under Ultrix; we have
version 1.1 running under VMS. I should know in a week or so if I
can get CommonLoops up - rkj]
===============================================================================
[4] Subject: VAXLisp Flavors
Return-Path: <beer%case.CSNET@csnet-relay.arpa>
Here at the Center for Automation and Intelligent Systems Research we have
developed a number of tools and utilities for VAX LISP, one of which is an
implementation of Flavors. The distribution details are a bit vague right now,
but it looks like the object code will be public domain for a tape and a small
handling fee ($5 or $10).
The Flavors implementation is fairly complete except for a smaller number of
method combination types. It also currently depends on a rather hacked up
dynamic closure implementation for VAX LISP. However, we are currently working
on a more complete and efficient implementation which is also closer to "New
Flavors". This new implementation will not require dynamic closures.
I will be releasing a report sometime in the coming month describing all of
these facilities ... A number of other VAX LISP tools and utilities are also
described, such as a pattern-based top-level history mechanism, a pattern-based
apropro facility, an extensible top-level command facility, and an extensible
DESCRIBE facility. I'll probably post a message about the availability of
these facilities on AIList...
Randall D. Beer
Center for Automation and Intelligent Systems Research
Case Western Reserve University
Glennen Bldg. Room 312
Cleveland, OH 44106
(beer%case@CSNet-Relay.ARPA)
===============================================================================
[5] Subject: Object Oriented Transputer Programming
Return-Path: <duke@mitre.ARPA>
However, I question whether Common Loops, or probably any available
package, is likely to aid your project. You state that you intend to use
your object-oriented package (OOP) to model the system you intend to build
for the transputer net.
[My objective is use existing concepts (from Common
Lisp, Common Loops etc) as a pattern for
incorporating parallelism (via transputers) into
computer aided engineering workstations -rkj]
First of all, a good package for the VAX will probably have more features
than you are likely to want to develop for the Transputer (unless you plan
a large and expensive project). Also, you would need a full implementation
of Common Lisp on the transputer if you were going to try to port large
parts of the code from the VAX OOP to a transputer OOP. My concern would
be that the model implemented on the VAX would be too different from what
you would be able to implement on the transputer...
[Our concept consists of a VAXStation II/GSX
*augmented* by a transputer array (later to
evolve to Application Specific Integrated Circuits).
VAXLisp/Common Lisp runs on the VAXStation and
uses transputer networks as peripherals. The
only parts of Common Lisp which need to migrate
to the transputers are the parts required to
provide an overall workstation environment which
can be *fully understood* with CL/OOP concepts:
-rkj]
Here at Mitre in McLean, VA we are working on a project for doing
object-oriented programming on the BBN Butterfly. Our application is a
battlefield simulation. BBN has just begun beta-testing their parallel
lisp dialect at three locations in the US. One of the test sites is the U.
of Maryland, and we will be using their machine until we acquire our own
Butterfly later this year. The Lisp dialect on the Butterfly is like
Scheme, but BBN is modifying it towards Common Lisp. BBN has some people
working on adapting CommonLoops for their parallel environment
(shared-memory), but I believe that is a very ambitious project and I
question whether they will complete it by their planned date of mid-87.
Since we require an OOP for our project before that time, I have written a
small one in Scheme. Since there are only two people on our project, we
have to limit the scale of our efforts. However, I am quite happy with my
OOP, which has only been running the past few weeks. It has a substantial
array of features implemented with a small amount of code (~1000 lines). I
feel that its small size will make it easier to modify for a shared-memory
parallel environment. If you are planning to implement a Lisp dialect for
the transputer, you might consider Scheme. It is a simple language, and
there has been some standardization of it. MIT distributes a version
called CScheme (implementation of Scheme in C) that could possibly be
useful to you. [seems to be UNIX as opposed to VMS oriented]...
... I have recently learned more about the NCUBE computer, and it sounds
very impressive for a hypercube architecture. It uses a special VLSI chip
which implements a VAX-like CPU with floating point and communication
channels, so it has a level of integration similar to the transputer. The
NCUBE chip is supposed to be about twice the speed of the mid-range VAXes
(780?). Nodes are currently configured with 128K RAM, and each node is made
up of only seven chips, six memory and the special custom VLSI. In
addition to their complete systems (up to 1K processors), they sell a four-
processor board which will plug into an IBM AT. You can put up to four of
the boards in the AT. The prices I was quoted were about $10K for each
board and about $5K for software licenses. The AT software environment is
identical to their large machines. I think their operating system is
UNIX-like and they have Fortran and C languages.
[We are not tied to the Transputer; its a convenient
integrated circuit to learn with -rkj]
Duke Briscoe
duke@mitre
===============================================================================
[6] Subject: object... inmos...
Reply-To: WELLS@SRI-AI
My group at SRI (AI center, mobile robot) is developing code for a mobile
robot in a language which is basically a high level machine description
language which combines functional and declarative style (with all
unification happening at compile time). This language is nice for
expressing parallel architectures. Currently we compile to C programs for
sequential simulation. Someday we'd like to run these programs on a
parallel machine. I've toyed with the idea of hooking up a bunch of inmos
chips. The thought of the systems work is pretty intimidating. The
language we're using (REX) is implemented in common lisp.
--Sandy Wells
[REX is not in the public domain, but a report describing it may
be soon available -rkj]
===============================================================================
Others provided me with very helpful information, (especially
lanning.pa@Xerox), though not of general net interest.
______
IV. Task Elaboration
The project I am working on has been going on here for much longer
than the two months I have been a LLNL. So, I will provide a brief
overview of what I think we are trying to accomplish and then mail
pointers to other members of our team.
Basically, we are trying to improve the productivity of LLNL engineers
in areas where commercial products are not yet available. We have two
major efforts now underway 1) EAGLES and 2) the Systolic Array Project.
Dennis Obrien (Obrien@lll-icdc) manages both these efforts (among other
things).
Eagles is a user environment which allows multiple software coded to
be used through a single window oriented user interface. Using Objective
C, an object oriented preprocessor for C marketed by PPI, a set of tools
have been developed to bind interactive languages, graphics routines,
matrix editors, help systems all smoothly together so users need only
learn one interface. This system (for Control Engineers) has just been
released to beta test. Brian Lawver manages this effort. Queries should
probably be sent to Obrien@lll-icdc, since needless to say, Brian will
be quite busy for a while.
The Systolic Array Project will evaluate the Transputer chip, build
two test boards, design a processor and interface board which can be
plugged into a VAXStation. The test boards are running, and the processor
board has been designed, pending the conclusion of transputer testing.
The current plan is to put 2x8 arrays of transputers on each board (4
boards initially), each with 128KB of memory. Board layout should start
in May, and we hope to have something running by August. Tony Degroot
(Degroot@lll-icdc) is managing the Systolic Array Project, and Eric
Johansson (johansson@lll-icdc) is most intimately involved with the
hardware design.
My job is to tie these two projects together, and I would like to do
it with common lisp, because I think over the long term there will be
more industry support for Common Lisp than any other plastic, interactive
environment. But I have to convince Brian that objects can be supported
as well by Common Lisp extensions as they are in Objective C, and I
have to convince Tony that Transputers can be programmed (at a minimum)
from a Common Lisp environment as well as they can be programmed in
OCCAM and its development environment.
My primary interest is in 1) defining a Common Lisp kernel, 2) extending
the kernel to support object oriented programming exploiting parallel
hardware, 3) defining an architecture which cleanly binds the kernel to the
parallel hardware, 4) implementing Common Lisp within this architecture.
Insights, collaborations, (or perhaps an occasional constructive criticism
on a good day) are solicited and will be appreciated.
+-----------------------------------------------------------------------------+
|Richard Jennings Arpa: (new) jennings@lll-icdc |
|POB 808 L-228 |
|LLNL, Livermore CA 94550 |
+-----------------------------------------------------------------------------+
Computer Aided Engineering
Dennis Obrien
Systolic Array Applications
Tony Degroot
Computer Aided Engineering Workstations
Brian Lawver
Supporting Objects With Parallel Hardware
Richard Jennings
Richard Jennings
PO Box 808 L-228 (L-228 is CRITICAL)
LLNL
Livermore, CA 94550
ARPA: preferred -> jennings@lll-icdc
slow, reliable -> jennings@lll-crg
(INMOS is a company which has probably trademarked OCCAM and
TRANSPUTER)
------------------------------
End of AIList Digest
********************
