From: ······@cs.rochester.edu
Subject: Re: environments
Date: 
Message-ID: <5056@sol.ARPA>
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
······@cs.rochester.edu
allegra!rochester!miller

From: Steve Clark
Subject: Re: environments
Date: 
Message-ID: <338@siemens.UUCP>
In article <····@sol.ARPA> ······@cs.rochester.edu writes:
>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.
I do that all the time in Interlisp-D, although more often I put each chunk
into a separate, small file.

>As an example that may prove this: consider trying to get a Dmachine to
>grock WEB (Knuth's language).
sorry, I don't know WEB and I don't have time to learn it.

>Personal prejudice: back in the days when I used franz under unix, I hated
>the structure editor.
I cannot comprehend using a tty-based structure editor.  If I have to do
Lisp from a tty, I will use Emacs.

>Brad Miller
>University of Rochester Computer Science Department
>······@cs.rochester.edu
>allegra!rochester!miller

Steve Clark, princeton!siemens!steve, ·····@siemens.com
From: Darrel VanBuer
Subject: Re: environments
Date: 
Message-ID: <5028@sdcrdcf.UUCP>
In article <···@siemens.UUCP> ·····@siemens.UUCP (Steve Clark) writes:
>>Personal prejudice: back in the days when I used franz under unix, I hated
>>the structure editor.
>I cannot comprehend using a tty-based structure editor.  If I have to do
>Lisp from a tty, I will use Emacs.
>
>>Brad Miller
>>University of Rochester Computer Science Department
>>······@cs.rochester.edu
>>allegra!rochester!miller
>
>Steve Clark, princeton!siemens!steve, ·····@siemens.com

I have used various interlisp versions for almost 10 years, and certainly
agree that the old teletype structure editor is almost never the editor of
choice now.  On the D-machines I will almost always use Sedit or Dedit (and
would not even consider using unix emacs on the source files).  Sedit is
almost as much better than Dedit as Dedit was than TTYedit (for those
outside the Xerox D environment, Sedit combines some of the best of Dedit
and an emacs interaction style).
I will still occasionally use TTYedit:
  To make a small change in a very large object (to save substantial screen
	painting time).
  To edit circular structures (display editors tend to loop printing)
  To write programatic transforms (e.g. dialect translation with Transor)
Only the last of these might justify learning how to use it.  The problem
with learning and using the TTYeditor with anything approaching the
efficiency of the display based editors is the 60 pages of commands, which
if you know them all, means you have a command for almost any conceivable
edit, but if you know only a few you have very tedious editing.

-- 
Darrel J. Van Buer, PhD; unisys; 2400 Colorado Ave; Santa Monica, CA 90406
(213)829-7511 x5449        KI6VY        ······@CAM.UNISYS.COM   or
...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj