From: utzoo!decvax!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: Commands for Structure Editors
Article-I.D.: ucb.1719
Posted: Sat Aug  7 05:35:48 1982
Received: Sun Aug  8 00:15:27 1982

>From decvax!harpo!npoiv!npois!cbosgd!mark@Berkeley Sat Aug  7 05:32:52 1982
Neither Ellis Cohen's bibliography nor Richard Waters' mentions any
of the literature on text-oriented language editors.  People seem
to think this means EMACS, but EMACS is NOT a language editor, it's
just a very clever text editor.  (A true language editor keeps more
of a data structure than just text.  I don't know of an EMACS
implementation that keeps a parse tree or symbol table around.)
I know of four text oriented language editor projects, which
I'm enclosing in a bibliography at the end.

I think Ellis Cohen is taking a middle ground - his ideal language
editor appears to have a "correct but possibly incomplete" parse
tree as a data structure, but a user interface that tries to be
more text-oriented than that of template editors such as the
Cornell Synthesizer and IPE.

>From my point of view, there are two fundamental problems with
template oriented language editors.  First, the user interface
forces the user to be painfully aware of the tree structure.
Second, the data structure is overly restrictive of the user,
because incorrect programs cannot be represented, and because
the user can't format the program (indenting, comments) exactly
as desired.

Cohen's ideas appear to go far toward solving the first problem.
Whether they can really be implemented in the general case is
unclear - what he's proposing sounds like incremental parsing
on every keystroke, with no lookahead.  Sounds hard, although
he gets to define his data structures and might include things
other than a FSM and a stack.  The whole parse tree is there,
and auxillary data structures might be useful.  Also, it might
be possible for the parser to make the wrong decision, as long
as it corrects itself when it sees the next few tokens.

I claim it's crucial for the user to be able to sit down and
type in his/her program EXACTLY as it appears written on a
piece of paper.  Otherwise there is yet another language the
beginner has to learn, and this would be a significant learning
barrier.  I am not convinced that Cohen's idea can do this,
although it might be able to.  Maybe for a restricted set of
grammars.

Cohen's solution does not address my second objection, except
briefly for issues such as turning if-then into while-do.
I claim that you can't anticipate all the textual changes the
user is going to want to make (to compensate for textual typos
that were made when typing in the textual program), and that
even if you can, forcing the user to learn a separate command
for each one is not good human engineering.  Let's face it,
the text interface is very easy to learn and very powerful.

Cohen's claim that text interface editors must do incremental
parsing if they keep a parse tree is correct.  And there is
no denying that incremental scanning and parsing make the
editor considerably more complex.  However, in my thesis (I
actually built one of these text interface language editors)
I found that the incremental scanning and parsing is pretty
cheap.  The really expensive part is incremental semantic
analysis, e.g. checking for undeclared variables and type
mismatches.  Both the template approach and the text approach
have (almost) exactly the same problem here.

Another problem with the template data structure is the handling
of preprocessors.  In a language such as C, it is nearly hopeless
to provide the power of the C preprocessor using templates.

	Mark Horton
	Bell Telephone Laboratories

C. N. Alberga, et al "A Program Development Tool", IBM TJ Watson Research
Center,  Yorktown Heights, NY 10598 (Sept 1979).

M. R. Horton, "The Design of a Multi-Language Editor", Ph.D. Thesis,
U.C. Berkeley, July 1981.

J. M. Morris, et al, "The Design of a Language-Directed Editor for
Block-Structured Languages", SIGPLAN June 1981.

T.R. Wilcox, et al, "The Design and Implementation of a Table Driven,
Interactive, Diagnostic Programming System", CACM November 1976.