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!philabs!seismo!rochester!dean From: dean@rochester.UUCP (Mike Dean) Newsgroups: net.cog-eng Subject: Re: Ford Clic Message-ID: <3192@rochester.UUCP> Date: Mon, 3-Oct-83 12:34:11 EDT Article-I.D.: rocheste.3192 Posted: Mon Oct 3 12:34:11 1983 Date-Received: Wed, 5-Oct-83 08:48:40 EDT References: rocheste.2969, <2113@tekecs.UUCP> Organization: U. of Rochester, CS Dept. Lines: 84 (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)