From: utzoo!decvax!cca!Zellich@OFFICE-3@sri-unix
Newsgroups: net.works
Title: Re: End User Interface a la Augment/NLS
Article-I.D.: sri-unix.2246
Posted: Fri Jul 23 05:34:40 1982
Received: Mon Jul 26 00:09:39 1982

True, you may have problems if you drastically change commands; this
has zapped us a few times in using Tymshare's evolving version.  It
helps a lot though, if you advertise the "gotcha" type changes when
you field the new release.

Note that the Augment/NLS interface uses \full words/ in command
files, rather than single command-characters.  Thus, the command files
are not at all cryptic, and tend to just bomb out rather than doing
the wrong thing if the command language changes and you forget to
update a command file.

There is no real problem renaming commands with the Augment/NLS user
interface (if the particular program is designed that way - the
"regular" subsystems aren't).  The grammar parser is working from a
table describing what is to be collected from the user next, and what
to do with it.  It allows not only literals in the command table, but
also variables and list-variables.  Thus, in some of our subsystems,
we have allowed the users to change the standard command words by
simply carrying them as useroptions and stuffing the words into a list
structure which is passed into the grammar-table environment.  You
still have the problem of a particular user not thinking too clearly
and defining duplicate command words, but that can be checked for in
the "Define" (or "Rename" or "Change Command-word", or whatever you
want to call it) command.  You could \also/ check for first-letter
duplicates, and warn the user if you wanted to, so multiple characters
wouldn't be required to invoke the duplicate commands.

There are problems possible with single-character command invocation,
but you can solve most, if not all, of them by careful design.

Cheers,
Rich
-------