Path: utzoo!utgpu!water!watmath!clyde!ima!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: lisp environments Message-ID: <13786@think.UUCP> Date: 16 Dec 87 08:18:00 GMT References: <487@PT.CS.CMU.EDU> <460@cresswell.quintus.UUCP> Sender: usenet@think.UUCP Reply-To: barmar@sauron.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 26 In article <460@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > What the crux of this discussion has been >about is how CommonLisp seems to have made an incore, structure-editor >based development system very difficult, if not in general impossible. >I'm not complaining that people use text-based development tools. Only >that it's being made difficult for me to use my preferred tools. How does Common Lisp PREVENT you from using an incore, structure-editor-based development system? What facilities does such a system require besides EVAL, SYMBOL-FUNCTION, and COMPILE? And even if these weren't defined in Common Lisp, who says that the development system has to be written in portable Lisp; since there's no standard Common Lisp interface to display terminals, it couldn't be portable if it were a display editor, and I don't think you were talking about a line-oriented structure editor. For example, the Scheme standard doesn't include EVAL or COMPILE, yet there are incore Scheme development systems (I think most Scheme implementations include EVAL, it's just not in the standard because it violates the philosophy of the language). --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar