[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Symbolics & Sun-3 + Lucid Dev Envs
Date: Tue, 26 May 87 11:17 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Resent-Date: Tue 26 May 87 13:37:20-CDT
Date: Sat 23 May 87 01:44:19-CDT
From: Bob Boyer <AI.BOYER@MCC.COM>
The reason is
that I run almost all my Unix processes, including Lisp, in
"shell mode," which makes all the IO go through an Emacs
buffer, where the IO can be picked up with the usual Emacs
editing commands and moved to other buffers with the
greatest of ease.
I see. So the different processes can communicate data by using Emacs
buffers. In a sense, the Emacs buffer is addressible by all of them,
and sort of acts as a "shared address space" in a crude way. I wonder
how easy it is to write programs that can use this communications
mechanism? I wonder how easy it is to pass interesting data structures
through this mechanism?
This is one reason that we feel a shared address space (or, more
properly, "shared object-oriented address space", since you really only
address objects, never numerical locations (that is, you never worry
about whether two objects are contiguous, or which is at a higher
address, etc)) is a fundamental underlying requirement for a high
quality Lisp programming environment.
Communicating via emacs buffers / unix files works very well for ascii
oriented data and operations such as compile-defun or
edit-compiler-warnings. The human interface to the text editing
functionality in these operations is more uniform under Gnu Emacs than
on the lisp machine (ZTOP mode where are you?).
Although no Common Lisp specification exists for it yet: A shared
address space can provide a very flexible communication media for
lightweight processes. At least one Common Lisp vendor is already
shipping a Beta test implementation (modeled on the lisp machine
facility). Hopefully we will see high quality implementations of this
capability from most vendors within the next year.
With lightweight lisp processes, CLOS objects, and a condition
handling facility - I don't see any reason why the programming
environment on conventional machines will not come up to speed very
quickly. There will be some compromises: debuggers that only work
well with interpreted functions, tradeoffs between run time speed and
safety, ... These seem to me to be the fundamental things that a
tagged architecture lisp machine buys you. The windows, graphics,
lightweight processes, objects, editors, inspectors, and debuggers are
only a matter of time for lisp on conventional machines.
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: email@example.com PHONE: (512) 338-3533