Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!princeton!siemens!steve
From: steve@siemens.UUCP (Steve Clark)
Newsgroups: comp.lang.lisp
Subject: Re: lisp environments summary
Message-ID: <325@siemens.UUCP>
Date: Mon, 7-Dec-87 09:46:13 EST
Article-I.D.: siemens.325
Posted: Mon Dec  7 09:46:13 1987
Date-Received: Sat, 12-Dec-87 12:43:53 EST
References: <613@umbc3.UMD.EDU>
Reply-To: steve@siemens.UUCP (Steve Clark)
Organization: Siemens RTL, Princeton, NJ
Lines: 38

In article <613@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes:
>
>	Awile back I posted a request on what makes for a good envirnment.
>
>Every lisp system needs a DEBUGGER that WORKS. KCL comes with a debugger that 
  Yes, both a code debugger (print stack frames) and a data debugger
  (normally called an inspector), and of course you should be able to
  point at a datum in a stack frame and get an inspector on it, etc.

>Multible chains. I like this, because it means distributing the system and I
>have limited heap space. But I'm not sure exactly what this means as far as
>local/global bindings. (perhaps something similar to UNIX fork(), with common
>bindings up to the fork, local after that?)
  That sounds fine, doable, and workable.  (Although I don't understand
  how heap space relates.)  Interlisp-D does this for its multiple-process
  capability, although there is only one level at which new processes fork.

>File system interface. [...]  I have considered a hypertext type of system,
[...]
>the idea of writing a file and sending it to lisp seems wrong,
  
  The correct way to deal with files and storing your lisp code is
  essentially the way Interlisp does it.  You edit your functions
  in Lisp, and when you want to save them you write them out to files.
  Furthermore, a file is treated as a database of definitions - function
  definitions, record definitions, data definitions, etc. etc., and the
  system keeps track of what you change and where it belongs and lets you
  know what files need to be rewritten.  (This is the equivalent to Unix
  "make" for a system where you edit things "in core".)  Unfortunately,
  CL has the wrong idea of files & editing somewhat wired into it.
  

  You also made some remark about needing a Symbolics or an Explorer.  If
  your interest is environment (rather than megamemory, megaspeed, or
  megabucks), you should consider the Xerox D-machines.  They are vastly
  underrated.

  -Steve Clark, steve@siemens.com (or @siemens-rtl.com)