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)