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