dean@rochester.UUCP (Mike Dean) (09/18/83)
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.
brucec@tekecs.UUCP (Bruce Cohen) (09/19/83)
I'd like to hear more about the clic project. I'd also like to hear from people who are working on or with other implementations of user interface management systems. Putting the interface in a separate module/subsystem/library from the application program seems like a good way to get consistent interfaces across a set of commands, but I somehow don't think it's quite that simple. What are the advantages and problems that pop up when you try to build and use such systems? Bruce Cohen UUCP: ...!teklabs!tekecs!brucec CSNET: tekecs!brucec@tektronix ARPA: tekecs!brucec.tektronix@rand-relay
shebs@utah-cs.UUCP (Stanley Shebs) (09/20/83)
Hmmmm, that standard command interface implementation (how's that for buzzwords?) reminds me of the Micropolis DOS for micros. It had something similar - a small library of functions that it used to parse commands and that were available to the programmer. Awful syntax - the filenames had to be in quotes, numbers were always hex, etc - but it was so easy to use that I never got motivated to write my own parser for commands stan the l.h. utah-cs!shebs ps overall, MDOS is one of the worst software systems ever inflicted by humans on other humans...
dean@rochester.UUCP (Mike Dean) (10/03/83)
(Sorry to take so long to submit this; it's been sitting in my electronic out-bin for quite a while now. The original query from tekecs!bruce was asking about the advantages and problems of building/using systems where interface descriptions and command implementations are separate. This was primarily in response to my earlier transaction discussing the Clic project at Ford. I'll also try to get some more information on that, including an example, out in the next couple days). I really can't think of any problems we encountered in Clic as a direct result of our separation of powers. There are several features that make Multics a very attractive environment for developing something like this, though, and I won't pretend to assume that it could be done as easily on other systems (including our beloved Un*x). The nice features about Multics include: 1) The flat memory system (this is the biggie, in my opinion). Everything in the file system hierarchy is directly addressable/manipulable as memory, which makes things like dynamic linking of subroutines possible. The interface components (command definitions, user-tailorable interfaces, argument parsing/validating/editing routines) don't have to come together until the user starts playing with them in his process. This affords a tremendous amount of flexibility, which I couldn't imagine if everything had to be stuffed in libraries and bound beforehand. As an example, we're also able to use the same mechanisms (directory search rules) for locating all components; this eliminates a lot of "version synchronization" problems, and gives us a totally dynamic command space. It also made the implementation much simpler (less than a man-year has been expended thus far). 2) Multics already has an amazingly standardized command syntax (particularly amazing since it's the result of a review committee's decisions over the years, and not dictated by standardized software). I see a distressingly-large number of different command syntaces appearing in Un*x software (witness the discussions in this group). 3) PL/I (Clic's implementation and target language) allows structures to contain the extents for variable-sized arrays which are also members. Thus, the "include structure" (so-named because an include file defining it is produced as a by-product of the command definition compilation) for the "ls" command can say "the user specified n paths and they are ..." without having to worry about artificial upper bounds or wasted space/bad data. The storage facilities (see (1) again) of Multics also made it relatively easy for the Clic run-time to build this structure (word-by-word) and get it mapped into the client's address space. Perhaps this will satisfy/confirm some of your intuitions regarding the simplicity of such a model. In doing Clic, we had a very nice toolchest for implementing our ideas. The big advantage to separation, as I see it, is the ability to defer many of the most expensive decisions (in terms of repair costs when you change your mind) and let them be made by specialists or, ideally, the user. In writing a command, I don't need to worry about the interface technology employed, checking the validity of the arguments (a very tedious task manually, if you have the stomach to code it right), or about the on-line help facilities. In constructing interfaces, if I want to add a -- or -h help convention to my command-line, it's a trivial change that immediately applies to all commands for which Clic definitions exist (perhaps, eventually, all of those in the standard libraries). I can also provide definitions for system commands that don't use Clic, and still get all the external benefits as a user. One can argue that keeping all the pieces in sync in such a system might be difficult (several people I talked with favored embedding the command definition in the implementation source and letting a preprocessor extract it, thereby reducing the number of source segments), but in practice this doesn't seem to be much of a problem (particularly with installation tools similar to "make" and object segments that contain the paths and modify times of all source and include segments used to create them). I'll be looking forward to other people's comments. In particular, I've been meaning to ask ulysses!kpv about his prototype language and interpreter (I think our original submissions crossed); perhaps he'd be willing to share some of his experiences with the net. Mike Dean dean@rochester MDean@Ford-Multics (if it ever gets real net connections)