Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tektronix.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!robertd From: robertd@tektronix.UUCP (Bob Dietrich) Newsgroups: net.lang.c,net.lang.pascal Subject: Re: Language transitions Message-ID: <5177@tektronix.UUCP> Date: Mon, 4-Mar-85 20:12:57 EST Article-I.D.: tektroni.5177 Posted: Mon Mar 4 20:12:57 1985 Date-Received: Wed, 6-Mar-85 14:07:01 EST References: <252@gumby.UUCP> <535@ukma.UUCP> Organization: Tektronix, Beaverton OR Lines: 51 Xref: watmath net.lang.c:4629 net.lang.pascal:260 > > Of course this is by no means the only problem with Pascal's I/O. Other > major ones include: > - no random access > - no way to open a file with a specified name from with the program. > reset(input,'foo') is an extension. It is not in the standard. > - no I/O of enumerated types (nor input of Booleans) > - the representation of files other than text is not defined. This > means that you can't write records onto a tape and expect to > read the tape on a different system. > I have never seen a program that I needed to write that could be written > in standard Pascal. General comment: Good article, Charles. I guess I'm not certain what sorts of programs you need to write, although having seen (and used) your systems programming extensions to the DEC-10 compiler, I have my suspicions. If, indeed, you want to do very environment- specific things in "standard" Pascal, and cannot do so, I'm not surprised. A standard should be implementable on a broad variety machines, and fails if what it specifies cannot be implemented. From where I sit (at my micro- programmable PERQ), I have access to one or more of the following machines, using Pascal: CDC Cyber, DEC-10, DEC-20, DEC VAX, IBM 3080, Motorola 68000, Intel 8086, National 32000, and a few others. There's more than one OS available for several of these. However, there's not much either the hardware or the various OS's agree upon in a consistent manner. As far as the problems you cite, JPC has approved Candidate Extensions for the first two items. The second two pose problems of definition and semantics. I/O of enumerated types has been suggested, but no one has taken the time or effort to try and define what this really means. It certainly poses additional problems for error recovery on user input mistakes. I'm not sure what you mean when you say that the representation of files other than text is not defined. The closest thing textfiles have defined as far as representation goes is that they are sequences of characters broken into lines. Nothing is specified about character set, length of lines, representation of the line marker, etc., in keeping with the separation of the language from its implementation. What would you want for any file? Do you want character values specified as EBCDIC? ASCII? Do you want a standard to require files of records to be aligned on 8-bit boundaries (on a DEC-10/20 with 36-bit words?) ? I feel I'm not understanding your point. I am very much in favor of portability, but specifying a language so that it can be implemented on a wide variety of machine/OS combinations is difficult. 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