Path: utzoo!mnetor!uunet!husc6!bbn!rochester!daemon From: miller@cs.rochester.edu Newsgroups: comp.lang.lisp Subject: Re: environments Message-ID: <5056@sol.ARPA> Date: 9 Dec 87 22:32:55 GMT Sender: daemon@cs.rochester.edu Lines: 31 I think most of the discussion so far has pretty much ignored one telling point: it depends on how you are going to *use* your lisp(m). If, as I and several other researchers do, you use lisp as a good tool for writing another language (which may be more or less lisplike) what you want to have is a clean path to upgrade the tools that work with lisp to work with your language as well (implemented in lisp). The emacs/text file paradigm gives me this. I don't think the structure editor approach always would: the syntax of the language may not lend itself to cleanly defined structures a/la an editor. A side issue on the text file: it allows a user-specifiable grouping on which functions are to be viewed togeter, i.e. that constitute some semantic chunk. As an example that may prove this: consider trying to get a Dmachine to grock WEB (Knuth's language). Personal prejudice: back in the days when I used franz under unix, I hated the structure editor. I always found a text editor, that understood structures , but allowed me to ignore them to be much more intuitive. Because, when you get right down to it: that keyboard was made for telling the computer something in english (written). You may temporarily restrict yourself to some other language, but you shouldn't be limited to it. Brad Miller University of Rochester Computer Science Department miller@cs.rochester.edu allegra!rochester!miller