From: utzoo!decvax!ucbvax!C70:editor-people Newsgroups: fa.editor-p Title: Commands for Structure Editors Article-I.D.: ucb.1659 Posted: Sat Jul 31 06:30:11 1982 Received: Sun Aug 1 01:18:28 1982 >From Ellis.Cohen@CMU-10A Sat Jul 31 06:26:22 1982 The recent SIGPLAN Notices contained an article by Richard Waters on why program editors should retain text-oriented commands. I believe that it is not necessary to retain a text-oriented viewpoint at all (except for dealing with text - i.e. comments, documentation). Enclosed is a short article which lays out my reasons. Comments? Text-Oriented Structure Commands for Structure Editors Ellis Cohen Computer Science Program Brandeis University Waltham MA 02254 Abstract The main problems associated with program structure editors are not inherent and can be solved without reverting to a textual viewpoint. Cursor movements can be made more natural by viewing the screen as a 2-D arrangement of nodes. Expressions can be input from left to right by rebinding operator keys to commands more complex than simple template expansion. Transformations of program fragments can be accomplished by an editor which supports matching and instantiation of subtrees. Introduction Editors for programs typically operate using a textual viewpoint or a parse-tree viewpoint, treating the screen as either a two-dimensional screen of characters or as the @i(presentation) of a parse tree. These viewpoints are not easily juxtaposed and there has been some discussion about when text-based editing is appropriate [ Teitelbaum & Reps 81, Waters 82 ]. This note argues that a textual viewpoint is never necessary for convenient and efficient program editing. The textual viewpoint makes syntactic and semantic checking difficult or expensive. If the program is maintained only in textual form, then searching is constantly required to determine whether variables are declared and whether expressions are legal. If the program is internally maintained in both textual and parse-tree forms, then incremental parsing is constantly required to keep the parse-tree consistent with the text. In either case, the exact time at which checking or reparsing is to be done is unclear and facilities for reporting and supporting the correction of errors must be provided. The parse-tree viewpoint simplifies checking but, @i(as implemented in many current systems), has a number of drawbacks: Cursor movement is tedious and annoying, expressions must be input in Polish-prefix form, and textually simple transformations are difficult. In fact, none of these difficulties are inhertent to the parse-tree viewpoint. Cursor Movement Many people who have used tree-oriented cursor movement commands have found them to be uncomfortable. I believe that 2-D commands are indeed preferable, but @i(need not imply a textual viewoint). A better way of viewing the presentation of a tree is as a two-dimensional layout of tree nodes on a background (which for editing purposes can be totally ignored) of keywords. The nodes are hierarchically orgainized (i.e. parent, children, grandchildren, etc.), but the leaf nodes (identifiers, constants, and unexpanded templates) stick out the most. I believe that the most natural cursor movement will consist of up, down, left and right movements from one leaf node to another leaf node, with movement out to a parent node as the last step. In other words, in addition to cursor commands which follow the tree structure, I am suggesting that the editor include commands like beginning-leaf-in-line ending-leaf-in-line moves the cursor to the first or last leaf on the current line forward-leaf backwards-leaf moves the cursor forward or backward to the last leaf up-leaf-line down-leaf-line moves the cursor up or down to the next line which has a leaf node and positions to the cursor at the first node on the line (or should it be the leaf closest to the current position of the cursor). parent moves the cursor to the parent of the current node An additional data structure needs to maintain the two-dimensional arrangement of nodes with pointers back to the tree, but this can be easily generated as a side-effect of generating the display. Entering Expressions Structure Editors require that a parent node be expanded before its children can be filled in. When expressions are entered via the structure editor (as in ALOE[ Medina-Mora & Feiler 81 ]), it appears that they must be input in Polish prefix form. However, it is possible to obtain a left-to-right input style by judicious rebinding of keys. Ordinarily, if the cursor is at the template, the key '+' is bound to a command like expand-add-expression, which expands the template to + . If '+' is typed when the cursor is at an already expanded node, an error occurs. Instead, one could imagine '+' to be bound to a command like subsume-add- expression, which could be defined (in an Emacs-MLisp like way [ Gosling 81 ] as) (defun (subsume-add-expression (delete-to-killbuffer) (expand-add-expression) (child) (yank-from-killbuffer) (forward-node))) If the cursor were pointing at 17, then subsume-add-expression would move the subtree 17 to the kill-buffer, expand an add expression + , move the cursor to the left child and bring back the contents of the kill-buffer, obtaining <17> + , and then move the cursor to the node. The subsume code actually needs to be a bit more complex to take care of operator precedence correctly, since typing a '+' when the cursor is at 'b' in a * b should nonetheless delete and then yank a * b, not just b. Parentheses also need to be handled correctly. Transformations The textual viewpoint often appears as if it should simplify various transformations of program fragments. For example, to convert IF xxx THEN yyy to WHILE xxx DO yyy simply requires replacing IF with WHILE and THEN with DO. With many structure editors, this operation would in fact be quite tedious. However, Mentor [ Donzeau-Gouge 75 ] contains facilities for matching and instantiating subtrees. A single command could be defined to effect the entire transformation. Myte [ Rudell 82 ] under development at Brandeis extends this facility and allows the transformation command to be bound to a key or sequence of keystrokes. The binding could be made quite mnemonic -- for example, ^\iw, where ^\ (control-backslash) means transform and "iw" stands for "i"f to "w"hile. Using Mentor or Myte, it would be just as easy to bind ^\ir to a command which converts the if statement to REPEAT yyy UNTIL xxx or to bind ^\i~r to a command which would produce REPEAT yyy UNTIL NOT (xxx) References V. Donzeau-Gouge et.al., "A Structure-Oriented Program Editor", Tech. Report, IRIA-LABORIA, France 1975 J. Gosling, "Unix Emacs", Computer Science Dept., Carnegie-Mellon Univ., Pittsburgh PA, December 1981 R. Medina-Mora & P. Feiler, "An Incremental Programming Environment", IEEE Transactions on Software Engineering 7,5 (Sept 81) T. Teitelbaum & T. Reps, "The Cornell Program Synthesizer: A Syntax-Directed Programming Evironment", CACM 24,9 (Sept 81) R. Waters, "Program Editors Should Not Abandon Text Oriented Commands", SIGPLAN Notices 17,7 (July 82) M. Rudell, "MYTE: An Extensible Program Structure Editor", Tech. Report CS-82-104, Computer Science Program, Brandeis University, Waltham MA, May 1982