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 <
[email protected]>
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.
