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.