Aucb.103 fa.editor-p utzoo!decvax!ucbvax!C70:editor-p Wed Dec 2 23:05:07 1981 Cross-Product Languages >From LAWS@SRI-AI Wed Dec 2 22:54:09 1981 Greetings! As my first act upon joining your list I am forwarding a letter that appeared today on Human-Nets, along with my response. -- Ken Laws Date: 30 Nov 1981 22:30:34-PST From: decvax!watmath!idallen at Berkeley Subject: Command language names: the cross-product problem. Somewhere between the ambiguity of a full AI-emulating command interpreter and the uncomfortably rigid demands of conventional shells there lies a grey region. In this region I think it is possible make command interpreters less fussy about the names for objects and actions in the computing environment. We are all familiar with the great glee with which we approach a new operating system, trying out our favourite verbs and command names to see if the designers were tuned to our wavelength. Friendly systems might be the systems which name things the way we want them named... Reading the human-nets news, I see concerns that English might not be a good choice of language because of its ambiguity. If any model of English is to be considered for a command language, it would have to be the style of language one would use in situations where no visual cues are available, such as over a telephone. Even better -- it's the kind of dialogue you'd have to conduct by this mail system, where not even inflectional cues are possible. (EXCEPT THAT SOME PEOPLE CONSIDER THIS TO BE SHOUTING.) Research we're doing here at Waterloo is looking toward a means of allowing synonyms (in the real English sense of the word, with the necessary expansion to 'computerese' phrasing where necessary [who ever thought that SCRATCH was a reasonable synonym for DESTROY?]) in command languages. The title 'cross-product problem' at the top of this article is a reference to the tendency for designers to require a unique, short, mnemonic command name for every combination of action and object in the computing environment. This cross-product approach requires me to remember many more names than if the designers had let me remember the names for the actions and objects separately and combine them when I needed them. I have to remember 'rmdir', and 'rm' and 'lprm', etc., instead of just needing to know 'remove' and the names 'directory', 'file', and 'listing'. When I learn a new action, such as 'create', it is obvious how to apply it to 'directory' or 'file', but it is not at all obvious what the cross-product names could be. If I was now permitted to use a restricted set of synonyms for the components of a command, such as using 'scratch' as a synonym for 'remove', then naming commands becomes a rather more friendly operation. Exams call -- more on this later. Your comments are warmly appreciated. -IAN! (U of Waterloo, Canada) ------------------------------ Thanks to IAN! at U of Waterloo for bringing up the subject of cross-product command languages. I have been studying editor command languages lately, and I found that mnemonics and command factorization become extremely important as the language complexity increases. To be specific: the UNIX version of Emacs has exceptional potential as an operating system interface (thanks to James Gosling, David Kashtan, Andy Witkin, and no doubt others). As an editor, though, the vanilla version is very weak. Its only saving graces are that (1) it is adequate for many tasks, and (2) it is easily extended to do almost anything. The problem is one of too many commands and too little structure. At the hacker's level things are nicely factored with primitive names like delete-next-character, forward-character, forward-word, and forward-paragraph. At the user's level, however, these commands are known as control-D, control-F, meta-F, and meta-]. Delete-window is control-X D, delete-region-to-buffer is meta-control-W, and describe-word-in-buffer is control-X control-D. While there is reason behind this madness, the user interface is hopelessly inextensible. Of the ~250 defined commands only about 70 are initially bound to keys. Many of the primitives are not intended as interactive commands, but most of these are not bound simply because no one would be able to remember them all. Vi, the UNIX editor is much better suited to text file editing. It has very little extensibility, although later versions permit customization by rebinding. Macros are permitted, but they cannot take parameters. Vi does not have multiple windows or multiprocess capabilities. What it does have is several hundred commands all bound to simple mnemonic key sequences. Because vi has a sticky insert mode it can afford to use single-letter commands for most functions. Many of these can be combined: dw for delete word, db for delete-backward-word, de for delete-to-end-of-word, 3dw for delete three words, etc. This is combined with an extensive system of line numbers, named marks, and named temporary buffers to permit almost any manipulation of text regions. (Vi and vanilla emacs both lack NED's ability to pick up arbitrary text windows and move them to new starting rows and columns. Other than that vi has just about every imaginable capability.) The ZED editor has an even more systematic syntax. The Emacs version on my system is hopelessly inefficient and probably bears little resemblance to the original, but the potential of its syntax is obvious. The backward-delete-three-whole-words and forward-to- right-end-of-paragraph notation is uniformly implemented. A parser is used to expand strings of characters, such as 3bdhw, into the intended pseudo-English phrase. At present the parser is rather dumb: one must use "h" for "whole" to avoid confusion with "w" for "word". This is not an inherent limitation -- Twenex has long had the ability to do context-dependent command completion. In summary, I believe that all command languages -- editors, operating system interfaces, and other command drivers -- should use cross-product command abbreviations to the maximum extent possible. -- Ken Laws ------- ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.