Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site rochester.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rochester!dean
From: dean@rochester.UUCP (Mike Dean)
Newsgroups: net.cog-eng
Subject: Ford Clic
Message-ID: <2969@rochester.UUCP>
Date: Sun, 18-Sep-83 13:05:20 EDT
Article-I.D.: rocheste.2969
Posted: Sun Sep 18 13:05:20 1983
Date-Received: Sun, 18-Sep-83 22:12:51 EDT
Organization: U. of Rochester, CS Dept.
Lines: 53

I just discovered this newsgroup and am very glad to hear about it.  I
spent my summer working on a subsystem that addresses many of the
issues brought-up here (I'll discuss that below), and am very
interested in the subject area for thesis research as well.

Clic (the Command Line Interface Compiler) is being developed at Ford
Motor Company to facilitate the construction of interfaces to system
and application programs on Multics (an ancestor of Unix not nearly as
close to obsolescence as some would make out).  It's intended to make
life easier for both the programmer (via standard argument definition,
parsing, editing/validation, and default facilities) and user (via
several "enhanced" interfaces, including a TOPS20-like completer, a
prompter, and a fill-in-the-blanks form interface, as well as automatic
generation of manual pages).

One of the key points of clic is separation of the command definition,
argument parsing, and implementation.  The programmer defines the
command's argument requirements in a non-procedural language and feeds
it through the clic compiler.  This generates a standard object segment
which may then be located (via the same search lists used for commands)
by the enhanced interfaces or by the argument-parsing subroutine.  The
argument-parsing subroutine returns a pointer to a filled-in structure
containing all of the argument information in processed form (switches
become booleans, star-names are expanded, all argument values are
verified, etc.).  The format of this structure is defined by clic in an
#include file generated during compilation.

There are several advantages to this approach:

1) Commands don't have to do their own argument parsing.  With clic, it
takes about 5 lines of code within the command to get argument
information validated and delivered in a readily-usable form.  More
importantly, the program is not concerned with the mechanics of
acquiring the arguments and is immediately retargetable to new
technologies (command lines, forms, prompting, icons, network messages,
smoke signals, etc.).

2) Clic definitions can be provided for existing programs that don't
use clic for argument processing, thereby still providing the new
facilities (completion, on-line help, etc.) available from the enhanced
interfaces.  This is particularly important when you can't afford to
convert everything at once.

3) Interface definitions are grouped together.  This makes it easy to
check for consistency throughout the system.

4) Users are free to choose the style of interface they want, and may
easily write or clone their own.  Making use of the generic run-time
facilities, the clic_tops20 interface is only about 600 lines of PL/I
code (and most of that is terminal handling).

I can supply more details on clic if anyone is interested.  I'm really
looking forward to participating in this newsgroup.