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