mwm@ucbtopaz.CC.Berkeley.ARPA (02/17/85)
In article <2793@ncsu.UUCP> mauney@ncsu.UUCP (Jon Mauney) writes: >Of the many flaws in Pascal, ordinary I/O is not one. There is nothing >preventing good interactive execution of Pascal programs. >Jon Mauney mcnc!ncsu!mauney C.S. Dept, North Carolina State University Except (staying within the semantics of J&W, of course!): 1) Getting read/write to work as expected on an interactive system. I've heard that it can be done right while still maintaining the J&W semantics, but have never seen it so done. 2) Doing the *exact* equivalent of printf("Gimme data: "); with the cursor left at the end of the line. <mike
mauney@ncsu.UUCP (Jon Mauney) (02/18/85)
I say: >> Of the many flaws in Pascal, ordinary I/O is not one. There is nothing >> preventing good interactive execution of Pascal programs. <mike says > Except (staying within the semantics of J&W, of course!): > > 1) Getting read/write to work as expected on an interactive system. I've > heard that it can be done right while still maintaining the J&W semantics, > but have never seen it so done. > > 2) Doing the *exact* equivalent of printf("Gimme data: "); with the > cursor left at the end of the line. The trick is to do lazy evaluation on input, and to be careful how you buffer the output. The definition of I/O in J&W is very simple, concerning itself with contents of the file pointer and the values of the eof and eoln flags. Despite what the implementers of UCSD Pascal seem to think, it is not necessary to get the next input character until the code actually tries to use it. Berkeley's Pascal compiler does lazy evalution of input, and it works just fine; about the same as C, in fact. As for write('Gimme The Ax: '); J&W say nothing about buffering the output, so there is nothing to prevent write statements from having an immediate effect. I have written interactive programs in Pascal, and they conform to a reasonable interpretation of Jensen and Wirth. -- *** REPLACE THIS LINE WITH YOUR SIGNATURE *** Jon Mauney mcnc!ncsu!mauney C.S. Dept, North Carolina State University
alexis@reed.UUCP (Alexis Dimitriadis) (02/23/85)
> 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. If there is a way in standard Pascal to APPEND to a file, (without copying out its contents, wiping out the file, and putting them back in before the appending), it must be a closely kept secret. Alexis Dimitriadis alexis @ reed
mauney@ncsu.UUCP (Jon Mauney) (02/27/85)
From various sources: "Pascal I/O is defective because it provides > - 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. > - 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. > - no way to APPEND to a file, (without copying out its contents, > wiping out the file, and putting them back in > before the appending)" These arguments carry little weight with me, but, ever the open-minded type, I am willing to study the matter before rejecting it. To that end, I invite one and all to tell me what languages do provide these features, and how they accomplish it in a portable way. Respond by mail, I will summarize for the net. -- *** REPLACE THIS LINE WITH YOUR SIGNATURE *** Jon Mauney mcnc!ncsu!mauney C.S. Dept, North Carolina State University
sitze@rruxo.UUCP (R Sitze) (02/27/85)
Granted that Standard Pascal does not provide everything, prehaps a a more realistic view of the world should be looked at : > - no random access MOST pascals provide random access, and come to think of it, isn't the seek procedure standard???? > - 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. I've NEVER seen a pascal that did not provide this feature... If yours doesn't, then prehaps you have the wrong pascal... Don't complain about short comings due to a bad choice on somebody's part. > - no I/O of enumerated types (nor input of Booleans) No argument here, just a comment : HP's pascal that currently runs on both their 1000, 3000 and 9000 machines (I'm not sure about the 3000...) DOES provide this. Oh Glory Be... How I love that one.. My understanding is that they are or will be providing this on their micro's also, so prehaps it will be on all IBM compatables before all is long. Also, once one gets going, it'll spread like wild fire... (Hopefully...) > - 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. No arguments, but a little common since should solve this problem... Granted that sometimes common since doesn't apply in all cases... > I have never seen a program that I needed to write that could be written > in standard Pascal. I've never SEEN a standard Pascal implementation.. Not Even HEARD of such a thing... But then I'm young and ignorant too... And finally, Isn't this a news group for Pascal??? Let's talk about pascal and be nice people and help each other and all that other good stuff my mommy taught me to do... Lets talk Pascal, or as Monty Python put it... Look on the bright side of life... Thanx <ras> inhp4!rruxo!sitze
arnold@gatech.UUCP (Arnold Robbins) (02/27/85)
> > 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. > > If there is a way in standard Pascal to APPEND to a file, (without > copying out its contents, wiping out the file, and putting them back in > before the appending), it must be a closely kept secret. > > Alexis Dimitriadis > alexis @ reed One of the proposed extensions to Pascal described in the July 84 Sigplan Notices is and extend(f) procedure, which positions to the end of 'f', and leaves it open for writing. Another extension is for random access (seeking). There is other work in progress to give Pascal some decent I/O. If they keep it up, Pascal may yet end up a decent language. Now if we just had own variables and compile time initialization.... -- Arnold Robbins CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold Help advance the state of Computer Science: Nuke a PR1ME today!
ndiamond@watdaisy.UUCP (Norman Diamond) (02/28/85)
> From various sources: "Pascal I/O is defective because it provides > - no random access Fortran-77, PL/I, and Cobol can do this in a portable manner. (They can also do it in dozens of non-portable manners, which is irrelevant.) > - 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. Fortran-77 can do this in a portable manner. Of course, the file name (contained in a character string) must be recognizable by the operating system. Believe it or not, Fortran beats PL/I and Cobol this time, because PL/I's "title" option is non-portable and Cobol cannot specify the actual filename in a "select" statement (at least, not portably). > - 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. That is a demand that all systems should be identical, which is antithetical to the concept of portability. You'll never see that. > - no way to APPEND to a file, (without copying out its contents, > wiping out the file, and putting them back in > before the appending)" In Fortran, you can read to the end of a file and then start writing -- that's only half as bad. For that matter, the "open" statement might include positioning information; I don't remember. Please observe that the C LANGUAGE provides none of these capabilities. If you want to talk about LIBRARY ROUTINES, they can be added to ANY language. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
rcb@rti-sel.UUCP (Random) (03/04/85)
Try VMS Pascal. It comes closest to a perfect pascal that I have seen. Random Research Triangle Institute ...!mcnc!rti-sel!rcb
robertd@tektronix.UUCP (Bob Dietrich) (03/05/85)
> > One of the proposed extensions to Pascal described in the July 84 Sigplan > Notices is and extend(f) procedure, which positions to the end of 'f', > and leaves it open for writing. Another extension is for random access > (seeking). There is other work in progress to give Pascal some decent I/O. > > If they keep it up, Pascal may yet end up a decent language. Now if we just > had own variables and compile time initialization.... > -- > Arnold Robbins > CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa > UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold Surprise, Surprise. JPC has recently approved a separate compilation (modularity) extension that allows "own" variables. Also, a while back we put a value initialization extension into the CEL (Candidate Extension Library). We're trying. 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
robertd@tektronix.UUCP (Bob Dietrich) (03/05/85)
> > 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
ee163acp@sdcc13.UUCP (DARIN JOHNSON) (03/07/85)
> Try VMS Pascal. It comes closest to a perfect pascal that I have seen. > When I used VMS Pascal, I really liked it. However, as far as saying VMS Pascal is a perfect Pascal, I have to fudge a bit. It is similar to VMS FORTRAN in that there are major extensions to the language. I like these extensions, but I would think one would fall into the trap of writing programs useable only on that compiler (I am guilty too). So rather than call it a 'perfect' Pascal, I would say it is 'wonderful' Pascal. With enumeration I/O, variable length arrays (spent 2 weeks determining what the manual said and what really happens), initializers, and other goodies, I might even call it a 'nice Pascal-like language'. However, if by perfect you meant "just what I always wanted in..." rather than "comes close to most common standards..." then ignore the above. Darin Johnson