Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site tektronix.UUCP Path: utzoo!linus!decvax!tektronix!robertd From: robertd@tektronix.UUCP (Bob Dietrich) Newsgroups: net.lang Subject: Re: I/O operations in programming languages Message-ID: <1310@tektronix.UUCP> Date: Mon, 29-Aug-83 23:21:21 EDT Article-I.D.: tektroni.1310 Posted: Mon Aug 29 23:21:21 1983 Date-Received: Wed, 31-Aug-83 09:01:52 EDT Organization: Tektronix, Beaverton OR Lines: 97 I thought I'd reply to Michael Condict's (csd1!condict) discussion of I/O in programming languages. There seems to have been at least one other reply on the net from someone named umcp-cs!rehmi, but it was quite garbled. Something about hacking in a higher-level assembly language call C, and the fact that it's rarely found anywhere but in a Unix environment. I agree with most of Michael's comments, especially the fact that sequences were misnamed files. I have also fought this battle long and hard and loudly. (Perhaps this is a very good caution to be careful in picking terminology!) As far as Pascal goes, nothing is stopping implementors from providing random access to mass-storage via Pascal's random access abstraction, the array. The appearance of a variable in the program heading means only that it is bound to an object outside of the program. The mechanism and the allowed types is determined by the implementation, not the language. Also, the ANSI-IEEE Joint Pascal Committee has a proposal for using random access files. (By the way, if you want to attend the next meeting in October, see net.lang.pascal or contact me). A few comments seem in order relating to programming language design and implementation. First, language implementations are usually done quite separately from the file system. This means that the language implementor must map the abstraction of the language onto some predefined primitives provided by the file system. The trouble is that the necessary primitives may not be there, or else do a poor job of supporting the abstraction. The result is that it is useless to put a feature in a language that depends on file system support that is not universal, because that feature will simply not be implemented. The dictatorial approach (as in the DoD and Ada) doesn't work either. If keyed-file access were added to Pascal, would that mean your home computer (with wonderful cassette tape) couldn't run Pascal? I'm not arguing for the lowest common denominator in languages; it's just very hard to know where to draw the line. My second observation is that few programming languages reinvent the wheel; instead, a few corners are added in the hope that enough will make the wheel roll more smoothly. Thus the design is influenced heavily by others that have gone before (learning from mistakes is fine; keeping them is not) and by the environment the designer is currently working in. Pascal, although not as strongly influenced as FORTRAN was by the IBM 709 architecture, seems to have been influenced by the CDC Cyber operating system SCOPE. This is at least true in the use of the program heading for communicating information between the program and the outside world. CDC FORTRAN (and other languages?) has long provided this facility, but only for files (in the operating system sense). Pascal was also designed to provide this facility, but as Michael pointed out, was fortunately not limited to files in the program heading. Some evidence for Pascal being influenced by the CDC environment is the fact that unlike regular parameters, program parameters are simply mentioned in the heading and defined (given a type) later on in the program block. Most implementations, if they pay attention to the program heading at all, only allow files because 1) that's the way the first implementation, Pascal 6000, did it; 2) the P2/P4 portable Pascal compilers that fathered most Pascals in the world did it that way; and 3) most operating systems either don't know what a command line is or make it difficult to parse. My third comment relates to implementors (I am both a user and implementor of Pascal). Note: It's been suggested to me that the remainder of this text borders on flaming. Several things usually effect the way someone implements a language, often in such a way that the result is an extended subset of the language instead of the whole thing. For instance, 1) The implementor is rushed to get "something working", so the simple things like expressions are done first, and the parts that look harder are left to be studied and implemented "later". "Later" often never comes. 2) The implementor is invariably under some sort of deadline, so that the parts left to be implemented near the end of the schedule are implemented in a rush, and perhaps with less care. 3) Implementors, like most people, are uncomfortable with things they don't understand. Such things don't get implemented. 4) A particular feature in language X is "just like in language Y", and so that feature will be easy to implement. Right and wrong. Yes, in isolation the feature is just like another language's feature, but in relation to the rest of the language the impact is quite different (usually a disaster). This is especially true of grafting features from one language onto another. 5) The simple question is rarely asked: "Is the abstraction I'm looking for already in the language (perhaps in a form I'm not familiar with) ?" 6) The "creeping feature creature" grabs hold of the implementor ("If I add this feature, then I can eliminate 20 whole statements from my 5000 line compiler!!") 7) Some implementors are just plain lazy. Lest I seem to be merely maligning implementors, let me say a few words in their defense. Often an implementor is between a rock and a hard place. The implementor must take a language that the user expects to be clairvoyant and implement it in a relatively hostile environment. Usually the operating system has long since been frozen and the machine instruction set was designed by a electrical engineer that says "Huh??" when you use the term "software". An added benefit that we are fortunately moving away from is that the compiler has been specified (by someone else) to run in 2K bytes of memory and compile 20,000 line programs at 10,000 lines a minute on an 8080 with floppies. (Oh, and by the way, can you have it done next month?) Given the environment that implementors have had to work with, it's a wonder we have languages at all. Bob Dietrich Tektronix, Inc. (503) 629-1727 {ucb or dec}vax!tektronix!robertd uucp address robertd@tektronix csnet address robertd.tektronix@rand-relay arpa address