Symbolics & Sun-3 + Lucid Dev Envs

[Rob Pettengill <rcp@mcc.com>]

   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
   Resent-From: CMP.SLUG@R20.UTEXAS.EDU
   Resent-To: SLUG:;@SW.MCC.COM

       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.

;rob

  Robert C. Pettengill, MCC Software Technology Program
  P. O. Box 200195, Austin, Texas  78720
  ARPA:  rcp@mcc.com            PHONE:  (512) 338-3533
  UUCP:  {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp