dat0@freja.diku.dk (Dat-0 undervisningsassistent) (06/27/89)
Hello out there. I am a teaching a first year course of computer-science using Pascal. Since we are about to switch from CP/M-computers to MS-DOS-computers, I was wondering if there exist a truly standard Pascal-compiler running on MS-DOS-computers on the market. Does anybody out there know? Thanks in advance Kristian Damm Jensen (damm@diku.dk)
acm9@apple.ucsb.edu (Mike O'Brien) (06/28/89)
In article <4757@freja.diku.dk> dat0@freja.diku.dk (Dat-0 undervisningsassistent) writes: >Since we are about to switch from CP/M-computers to MS-DOS-computers, I was >wondering if there exist a truly standard Pascal-compiler running on >MS-DOS-computers on the market. I think everyone would agree that Borland International's "Turbo Pascal" is the current standard in MS-DOS. It compiles faster, and makes faster and tighter EXE files, than any other Pascal on the market. The vast majority of the people on this newsgroup also seem to use Turbo Pascal. The current version is 5.5, and it will set you back about $250 for the professional package (with the debugger). Mike O'Brien acm9@cornu.ucsb.edu
pim@unl.fctunl.rccn.pt (Pimentao) (06/29/89)
In article <2039@hub.ucsb.edu> acm9@apple.ucsb.edu (Mike O'Brien) writes: > I think everyone would agree that Borland International's "Turbo > Pascal" is the current standard in MS-DOS. It compiles faster, and > makes faster and tighter EXE files, than any other Pascal on the > market. The vast majority of the people on this newsgroup also seem > to use Turbo Pascal. Well, I'm not currently aware of Turbo Paswcal's version 5.5, but the earliest versions had some problems dealing with files; as I recall it, they were not able to use the standard commands get and put; or, at least there were some problems when using them. For myself, I strongly sugest the use of Microsoft Pascal. Besides several advantages such as the use of units (which are also available on latest Turbo Pascal versions) allows the correct use of all standard features of the Pascal Language. When I use the expression standard Pascal Language, I'm thimking about what was defined in "Pascal users Manual and report", by Niklaus Wirth and Katleen Jensen. Of course Turbo Pascal as lots of features that make it an interesting tool for software development; however, I don't think it is the best way to teach Pascal; users might be impelled to use non-standard features of this implementation, instead of thinking how they should solve their problems in the satndard fashion. Besides, Microsoft Pascal is not a programming environment; instead, it is a compiler, which helps people understanding the several fases of compiling and linking programs. Of course, this is my personal opinion... -- Joao Paulo B. Pimentao | BITNET/Internet: pim@fctunl.rccn.pt Centro de Robotica Inteligente | UUCP: pim@unl.uucp Uninova | ARPA: pim%fctunl.rccn.pt@mitvma.mit.edu Fac. de Ciencias e Tecnologia | PSI/VMS: PSI%(+2680)05010310::HOST::pim Universidade Nova de Lisboa | Fax: (+351) (1) 295-4461 2825 Monte de Caparica | Phone: (+351) (1) 295-4464 x.0460 PORTUGAL | Telex: 14542 FCTUNL P
PETERSEN@ctrvx1.Vanderbilt.Edu (Chris Petersen - VUCC) (06/29/89)
>From: IN%"acm9@apple.ucsb.edu" "Mike O'Brien" 28-JUN-1989 14:20 >In article <4757@freja.diku.dk> dat0@freja.diku.dk (Dat-0 undervisningsassistent) writes: >>Since we are about to switch from CP/M-computers to MS-DOS-computers, I was >>wondering if there exist a truly standard Pascal-compiler running on >>MS-DOS-computers on the market. > >I think everyone would agree that Borland International's "Turbo Pascal" is >the current standard in MS-DOS. It compiles faster, and makes faster and >tighter EXE files, than any other Pascal on the market. The vast majority >of the people on this news > >The current version is 5.5, and it will set you back about $250 for the >professional package (with the debugger). > >Mike O'Brien >acm9@cornu.ucsb.edu Are you mad? The question was 'a truly standard Pascal'! TURBO is so far from the standard that you might as well call it Modula or make it stop using the name Pascal... The files don't work quite standardly, they don't support file buffers like the standard and numerous other small examples. The fact that Turbo is the DE FACTO standard Pascal compiler for the MS-DOS world these days (at least it seems so) is no reason to say that it conforms to the standards for Pascal compilers! -Chris Petersen petersen@ctrvax.vanderbilt.edu P.S. In case you're wondering, I've worked in 5 different Pascals and 4 versions of Turbo... I'm not sure there is a standard Pascal compiler for the PC anymore, but if there is it is NOT Turbo.
soper@xenna.UUCP (Pete Soper,,,) (06/29/89)
From article <20139@adm.BRL.MIL>, by PETERSEN@ctrvx1.Vanderbilt.Edu (Chris Petersen - VUCC): >>From: IN%"acm9@apple.ucsb.edu" "Mike O'Brien" 28-JUN-1989 14:20 >>In article <4757@freja.diku.dk> dat0@freja.diku.dk (Dat-0 undervisningsassistent) writes: ( etc etc etc ) The last time I heard, Oregon Software offered an MSDOS compiler that is certified to ISO level 1 (i.e. ANSI + conformant arrays). They are in Portland Oregon in the USA. I sent their number to the original poster, but don't have it on me at the moment. I don't have any current connection with this company but worked with some of them a few years ago and can vouch for their integrity. They also offer Modula-2 and C++ products, but they were first targeted to Sun and Vax systems and I don't know the status of possible MSDOS versions. Don or Randy: Are you reading this? ---------------------------------------------------------------------- Pete Soper +1 919 481 3730 arpa: soper@encore.com uucp: {bu-cs,decvax,necntc}!encore!soper Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA
lth@uoregon.uoregon.edu (Lars Thomas Hansen) (06/29/89)
In article <2039@hub.ucsb.edu> acm9@apple.UUCP (Mike O'Brien) writes: >In article <4757@freja.diku.dk> dat0@freja.diku.dk (Dat-0 undervisningsassistent) writes: >>Since we are about to switch from CP/M-computers to MS-DOS-computers, I was >>wondering if there exist a truly standard Pascal-compiler running on >>MS-DOS-computers on the market. > >I think everyone would agree that Borland International's "Turbo Pascal" is >the current standard in MS-DOS. Turbo Pascal is by nobody's standard a Standard Pascal. It lacks parts of Standard Pascal (notably put() and get() and file windows), and it expands on the language in many (admittedly extremely useful) ways. It can be used to write most Standard Pascal programs in a portable manner, though it is not common to do so. If you are looking for a Standard Pascal, I would not recommend Turbo Pascal. As a matter of fact, it may be wiser to switch to Modula-2 as a teaching language, the sooner the better, since Standard Pascal is rather crippled by today's measures of Good programming languages. But I guess that was not the question... :> --lars
acm9@apple.ucsb.edu (Mike O'Brien) (06/29/89)
In article <20139@adm.BRL.MIL> PETERSEN@ctrvx1.Vanderbilt.Edu (Chris Petersen - VUCC) writes: >The fact that Turbo is the DE FACTO standard Pascal compiler for the MS-DOS >world these days (at least it seems so) is no reason to say that it conforms >to the standards for Pascal compilers! You're answering the question "is there a version of Pascal on MS-DOS compatible with UCSD pascal?" and I was answering "is there a Pascal on MS-DOS considered the standard?" Two different interpretations of the question make for two different answers. Good form there, Chris, resorting to a personal attack ("are you MAD?") because of a difference of interpretation. Mike O'Brien
ags@mentor.cc.purdue.edu (Dave Seaman) (06/29/89)
In article <2044@hub.ucsb.edu> acm9@apple.UUCP (Mike O'Brien) writes: >You're answering the question "is there a version of Pascal on MS-DOS >compatible with UCSD pascal?" and I was answering "is there a Pascal >on MS-DOS considered the standard?" Nobody mentioned UCSD Pascal, for a very good reason: UCSD Pascal is as far removed from the standard as Turbo is, but in a slightly different direction.
mlw@pyr.gatech.EDU (Michael Williams) (06/30/89)
Borland obviously left get and put out of turbo pascal for a reason.
Can anyone tell me why get and put are better than read and write?
Used in conjunction with the seek command, I find read/write almost
identical to array access for a file of records, which is quite helpful.
--
Michael Williams
Georgia Insitute of Technology, Atlanta Georgia, 30332
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!mlw
ARPA: mlw@pyr.gatech.eduts@chyde.uwasa.fi (Timo Salmi LASK) (07/01/89)
In article <8616@pyr.gatech.EDU> mlw@pyr.UUCP (Michael Williams) writes: >Borland obviously left get and put out of turbo pascal for a reason. >Can anyone tell me why get and put are better than read and write? Because get and put fulfil an elusive pascal standard, and are much more difficult to use than TPs read and write. So a computer science class can linger on their principles :-) Slightly more seriously, it is obviously true that the search for a standard pascal compiler for teaching programming principles and the usefulness of a compiler (such as TP for PCs) are two quite distinct matters (although I have never really accepted this myself). ................................................................... Prof. Timo Salmi (Site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: vakk::salmi Bitnet: salmi@finfun
jds@mimsy.UUCP (James da Silva) (07/01/89)
In article <18965@paris.ics.uci.edu> milne@ics.uci.edu (Alastair Milne) writes: >mlw@pyr.gatech.EDU (Michael Williams) writes: >>Borland obviously left get and put out of turbo pascal for a reason. >>Can anyone tell me why get and put are better than read and write? > > I suspect the reason was nothing more profound than a desire to simplify the > parse tables -- and the number of predeclared routines. (Though there is > perhaps a more substantial reason: they haven't implemented file variables > as pointers to the file window, which is what -- or close to what -- most > Pascal's do. See below about the consequences of not doing so.) > From the Turbo Pascal 3.0 Reference Manual, Appendix D: "The reason for this is threefold: Firstly, Read and Write give much faster I/O; secondly, variable space overhead is reduced, as file buffer variables are not required, and thirdly, the Read and Write procedures are far more versatile and easier to understand that (sic) Get and Put." The "faster I/O" comment has to do, I think, with whether or not you have to copy data into the file buffer (after get/before put). Remember that Turbo Pascal has its roots in CP/M; the extra space required by file variables could be very prohibitive in a 56 or 64k system. Turbo Pascal version 3 was a beautiful system. The editor/compiler/linker and library fit in 39K. No bells and whistles, but it was slim and fast, and it worked well. You could forgive it its warts and ommissions, because there wasn't anything else like it. If you didn't have $350 for a C compiler, it was either Turbo Pascal or BASIC. Borland could now easily slip in support for Standard Pascal into their bloated product, perhaps through an alternate library. Alas, they are too busy playing the Pied Piper to their customers; leading them down the Primrose Path of Creaping Featurism. Right now people are too charmed to realize that they are chaining themselves to Borland. If you are lucky, Borland will choose to support the inexpensive, RISC-based graphic Unix workstations of the early 90's, but you will not escape the $40 (or whatever) per annum tithe to get the latest update. No, you will pay it with a smile on your face. Sorry about the sarcastic tone; this has nothing to do with the article I'm replying to. Does anyone else agree with me? Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
d88-eli@nada.kth.se (Erik Liljencrantz) (07/02/89)
In reply to previous messages:
I write to different types of programs (and I believe they have to be regarded
as two different forms of programming):
1. Professional application development: Speed and features are the major
considerations. The ability to link in assembly language and create
graphics is very important and portability is of less importance.
2. Intersystem programming: For example developing a program to calculate
the mandelbrot set on your PC and then transfer it to a numbercrunching
(Cray, if I had one, but a Pyramid will do...) computer when it works.
My experience lies with PC's, Mac's and Pyramid, Turbo, Lightspeed and BSD
Pascal. It isn't easy to run the very same program on these machines, and
especially file handling is difficult. Turbo uses Assign(FileVar,Name);
Reset (FileVar); or Rewrite(FileVar); while Lightspeed & BSD uses
Reset(FileVar,Name); or Rewrite(Filevar,Name);. In BSD there is no Close
and some other differences. The Get/Put vs. Read/Write discussion: I deal
mostly with textfiles and they work the same (Read/Write).
What I like:
Turbo Pascal (& Borland)
Macintosh Toolboxes (It's documented as Pascal calls! What if the PC had
such an environment...)
Sure I would like a standard, but I wouldn't settle with less performance in
my applications just because some of my programs should be able to run on
other systems.
-- Erik Liljencrantz --
-- d88-eli@nada.kth.se --iwm@ic.ac.uk (Ian Moor) (07/04/89)
If you want Standard (as in ISO/ANSI) try Pro Pascal from Prospero. They were validating it last time I heard and their compiler is available for PC's and CP/M. Regarding GET and PUT, they are described in Wirth's book and in the standards, if they are omitted you will not be able to compile many Pascal programs. I guess that Borland omitted these to avoid having to implement the file buffer F^. Pascal lacks many things you need for real programming, like explicit connection to named files and direct access I/O. The problem is that most implementers add these in non compatible ways. A compiler really must have an option to warn about these.
scl@virginia.acc.virginia.edu (Steve Losen) (07/04/89)
Here are two reasons not to fear the ANSI Pascal Standard: First, the Standard does not discourage the development of extensions. A compiler can comply with the ANSI Pascal Standard and still have tons of extensions, provided that there is some way to either turn them off or issue warning messages (at the user's request) when the extensions are used. I feel that the features required by the Standard are far less ambitious than the extensions that products such as Turbo Pascal add on. The Pascal Standard is sort of a "least common denominator". In another article in this group, someone listed some fairly minor missing standard features from Turbo such as the procedures "get" and "put" and the ability to pass functions and procedures as parameters. Certainly these are no more difficult to implement than string manipulations. Furthermore, I recall seeing several articles in this newsgroup from people who wanted to pass functions as parameters in Turbo, so this is obviously a useful feature. Second, the Standard specifies an "accepted" implementation of the universal features of Pascal. For example, the scope rules of Pascal appear reasonably simple on the surface, but they can get a bit tricky in certain instances. Granted, the more subtle aspects of Pascal scope rules can only be illustrated by somewhat bizarre sequences of code, but they exist nonetheless. The Standard also nails down the rules for the "goto" statement (including the very useful non-local goto). It would be nice if all Pascal compilers agreed with each other in these areas. The Standard has removed a lot of ambiguity from the Jensen and Wirth Pascal Report (the original standard). Admittedly, there are a lot of applications that can't be written using purely Standard Pascal. But wouldn't it be nice to know that your Pascal compiler would correctly compile and run most Standard Pascal applications without you having to alter a single line of source code? -- Steve Losen scl@virginia.edu University of Virginia Academic Computing Center
schwartz@shire.cs.psu.edu (Scott Schwartz) (07/06/89)
In article <18965@paris.ics.uci.edu> milne@ics.uci.edu (Alastair Milne) writes: | mlw@pyr.gatech.EDU (Michael Williams) writes: | >Borland obviously left get and put out of turbo pascal for a reason. | >Can anyone tell me why get and put are better than read and write? | >Used in conjunction with the seek command, I find read/write almost | >identical to array access for a file of records, which is quite helpful. | | I don't know that GET and PUT are necessarily "better" than read or write, | but they are certainly more standard. Using them, I can transport typed | file I/O among a number of Pascal dialects; Turbo is the only one I know of | that overloads READ and WRITE, so it's the only one where that will work. Actually GET and PUT are much better than READ and WRITE. One reason is that you can interrogate the file variable without committing to read it. For example, to strip leading whitespace from the input stream, you do the following: while (input^ in [space, tab, newline, cr, formfeed]) do get (input) This works without side effects, so that it can be bundled up in a black box and called by anyone. Using read and write requires that the user maintain state information: global variables which get checked before doing any I/O. | As far as I'm aware, the principal impact of this substitution is that | porting things between Turbo and other dialects gets a little harder. I would say a lot harder. The example I give above makes it clear that you will have to add code to the application to duplicate the state info that the file variable normally maintains. This requres checking all calls to read and write to make sure they read from your pushed-back data if it is available. If you get paid by the hour, you've got it made. I'd start by typing in the unix stdio style library routines that Kernighan and Plaugher give in "Software Tools in Pascal". -- Scott Schwartz <schwartz@shire.cs.psu.edu>
obryan@gumby.cc.wmich.edu (Mark O'Bryan) (07/06/89)
> >In article <4757@freja.diku.dk> dat0@freja.diku.dk (Dat-0 undervisningsassistent) writes: > >>Since we are about to switch from CP/M-computers to MS-DOS-computers, I was > >>wondering if there exist a truly standard Pascal-compiler running on > >>MS-DOS-computers on the market. Check out Prospero Pascal. To the best of my knowledge it supports the full standard Pascal. I'd have to check to see if it's level-0 or level-1 comformance. If you need the address/phone # I can dig it out. They're based in the U.K., but they have a U.S. distributor that is both helpful and knowledgeable about the product. They'll even send you a demo disk if you ask them nicely. -- Mark T. O'Bryan Internet: obryan@gumby.cc.wmich.edu Western Michigan University Kalamazoo, MI 49008
milne@ics.uci.edu (Alastair Milne) (07/12/89)
schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >Actually GET and PUT are much better than READ and WRITE. One reason is >that you can interrogate the file variable without committing to read it. >For example, to strip leading whitespace from the input stream, you >do the following: > while (input^ in [space, tab, newline, cr, formfeed]) do > get (input) How does this constitute not commiting to read the file variable? You are doing exactly that when you dereference the file variable to get its window. I don't see how this differs at all from repeat read( input, ch); until not (ch in [space, tab, newline, cr, formfeed]); except that you first copy what would have been the file variable reference into another variable. Saving one variable seems to me a trivial difference in transport. Replacing the references so that all "input^"'s become "ch"'s is worse, but not much. >This works without side effects, so that it can be bundled up in a >black box and called by anyone. I/O almost always has side effects, because there's almost always something that can go wrong. I am not in fact happy with either of the loops above because neither realises the possiblity of I/O error. (BTW, in Turbo, if you fail to clear a non-zero IOResult by calling the function IOResult, all I/O attempts to/from that file will fail until the result is finally cleared.) To the extent, however, that your while loop is free of side effects, and can be called as a module, so is and can the repeat. >Using read and write requires that >the user maintain state information: global variables which get checked >before doing any I/O. Please elaborate: what state information? Maybe I should be seeing what you mean, but I don't. >I would say a lot harder. ....This requres >checking all calls to read and write to make sure they read from your >pushed-back data if it is available. Again, I'm not following: I see no pushed-back data in the loop you gave. The series of get's the while does is exactly equivalent to the series of read(ch)'s in the repeat I added. In fact, if the correct definition of read is used, they must be, because the read is simply "ch := input^; get (input);" Please don't take this as an endorsement of Borland's substitution: I wish they hadn't done it -- it has added to the inconvenience of some transport I've had to do from UCSD, and doubtlessly is doing and will continue to do the same for lots of other projects. As I said before, I think it's very much because they hadn't used a window implementation of file variables, and didn't want to change it, so the associated syntax needed for using GET and PUT wasn't available. >I'd start by typing in the unix stdio style >library routines that Kernighan and Plaugher give in "Software Tools >in Pascal". Anybody else like to see UNIX translated to Pascal? I must admit it's been a pet dream of mine for quite some time. Alastair Milne
gus@pyr.gatech.EDU (gus Baird) (07/12/89)
>Article 2169 of comp.lang.pascal: >>From: milne@ics.uci.edu (Alastair Milne) >Newsgroups: comp.lang.pascal >Subject: Re: Standard Pascal > >schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >>Actually GET and PUT are much better than READ and WRITE. One reason is >>that you can interrogate the file variable without committing to read it. >>For example, to strip leading whitespace from the input stream, you >>do the following: > >> while (input^ in [space, tab, newline, cr, formfeed]) do >> get (input) > > How does this constitute not commiting to read the file variable? You are > doing exactly that when you dereference the file variable to get its > window. I don't see how this differs at all from > > repeat > read( input, ch); > until not (ch in [space, tab, newline, cr, formfeed]); > > except that you first copy what would have been the file variable > reference into another variable. Saving one variable seems to me a > trivial difference in transport. Replacing the references so that all > "input^"'s become "ch"'s is worse, but not much. > >>This works without side effects, so that it can be bundled up in a >>black box and called by anyone. No! There's a TREMENDOUS difference between repeat read(FileVar,ch) until ch {is whatever}; and while FileVar^ {is not whatever} do get(input); far beyond the trivial savings of a local variable. The point is that that the version with read consumes the character that stops the loop. This means that the routine after the skiptill routine will have to be written to get its first character from the skiptill code, and get its others from FileVar. This constitutes an unconscionable tight coupling between the routines, needlessly complicating the program and adversely affecting reliability and re-usability. We want our procedures to be as loosely coupled as possible. Turbo "Pascal" is a good language and development system, but it ain't Pascal. That's why I won't use it in my courses, where I'm training up computer scientists. Pascal's frequently-damned I/O model is actually one of its very best features - budding computer scientists who understand that model are well equipped to deal with real-world I/O systems. -- gus Baird School of ICS, Georgia Institute of Technology, Atlanta, Georgia, 30332 ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!gitpyr!gus
andru@rhialto.sgi.com (Andrew Myers) (07/13/89)
In article <8736@pyr.gatech.EDU> gus@pyr.gatech.EDU (gus Baird) writes: > >> >> I don't see how this differs at all from >> >> repeat >> read( input, ch); >> until not (ch in [space, tab, newline, cr, formfeed]); > >No! There's a TREMENDOUS difference between > > repeat > read(FileVar,ch) > until ch {is whatever}; > >and > > while FileVar^ {is not whatever} do > get(input); > >far beyond the trivial savings of a local variable. > >The point is that that the version with read consumes the character >that stops the loop. ... This is true. Nonetheless, the difference isn't as great as you seem to think. What's really happening here? Pascal is giving you a one-record buffer that you can inspect without advancing the file pointer. However, we can implement this easily enough in Turbo's paradigm, by introducing a buffer variable tied to FileVar: reset(FileVar) -> reset(FileVar); read(FileVar,FileVarP); get(FileVar) -> read(FileVar,FileVarP); FileVar^ -> FileVarP If you're so inclined, you can bundle the file and the variable as fields of a record, and implement some alternate I/O routines that give you the abstraction. I've converted a number of programs from Standard Pascal to Turbo using this approach, and it works fine. Now, I agree with everyone else that Borland should not have changed the semantics of Pascal, but arguing purely from a standpoint of the language, it's a tossup. I certainly wouldn't pay anything for the file window abstraction. -Andrew >-- >gus Baird
RDK%vm.temple.edu@cunyvm.cuny.edu (Robert Keiser) (07/14/89)
ok, I've been watching the current disscusion about read/write vs. get/put
and I have a question. But first, let me tell you where I'm coming from.
I've worked on a Cyber using U. of M. Pascal and on pc's using Turbo. On
the Cyber's, to get interactive I/O to work correctly required you to first
declare the file input to be interactive (by placing a '/' after the filename
on the program statement (i.e. PROGRAM HELLO (INPUT/,OUTPUT);). The slash
tells Pascal not to do the initial GET on input. Then to read anything, you
first would have to issue a blank readln followed by your read. The code
would look something like this:
.
.
.
WRITELN('WHAT IS YOUR NAME');
READLN; (* FORCE A GET *)
I := 1;
WHILE NOT EOLN DO
BEGIN
READ(NAME[I]);
I := I + 1;
END;
.
.
.
Sorry about all caps but the Cyber doesn't have upper/lower case (normally)
and I wanted to be realistic. Anyway, the question, what would the same code
look like in say VAX Pascal or MS Pascal? I mean, it would seem that to
follow the way Pascal is supposed to work with the "look ahead" buffer it would
require something special to avoid the above example. (unless, of course, I
am completely missing something). For those of you who would wonder why I
would read in a string like this, its because Cyber's Pascal also didn't have
String capabilities. It was pretty close to the original that Wirth created.
As far as the I/O being one of Pascal's strengths, try explaining the above
example to a beginner. I've tried, the response is usually a quizzical look
and a shaking head.
Robert Keiserhaveraaen-magne@CS.YALE.EDU (Magne Haveraaen) (07/14/89)
In article <20239@adm.BRL.MIL> RDK%vm.temple.edu@cunyvm.cuny.edu (Robert Keiser) writes: >[...] Then to read anything, you >first would have to issue a blank readln followed by your read. The code >would look something like this: > . > . > . > WRITELN('WHAT IS YOUR NAME'); > READLN; (* FORCE A GET *) > I := 1; > WHILE NOT EOLN DO > BEGIN > READ(NAME[I]); > I := I + 1; > END; > . > . > . >Sorry about all caps but the Cyber doesn't have upper/lower case (normally) >[...] >As far as the I/O being one of Pascal's strengths, try explaining the above >example to a beginner. I've tried, the response is usually a quizzical look >and a shaking head. Explaining this programming style isn't so difficult, unless your student has a background from ForTran, or, which is sadly a very common case, the Pascal textbook author has a background in Fortran, and thus gives all kinds of misleading guidelines on how to program dialogues in Pascal. In Pascal 'readln' does not read-a-line, but reads-to-the-next-line. It acts as a synchronization utility, synchronizing the writeln with the next input line, removing all unwanted trailing characters from the preceding input line. That is why you should not supply the 'readln' procedure with any parameters, as these parameters will be given values from the previous inputline, before the synchronization takes place. But some dialects of Pascal did not conform to this, and it seems that most textbook writers have tested their programs on compilers that have non-standard input handling, making the teaching of standard Pascal quite difficult. Over to the more general question of get/put vs. read/write. The example skip-blanks is a good one: procedure skipBlanks (var input : text); (* note input is a file variable parameter, not the textfile input *) (* routine advances file pointer over blanks to the point where something interesting may be read *) begin while (input^ in [space, tab, newline, cr, formfeed]) do get (input) end; So let us use this in a program: program niceDialogues (input, output) ; : var age : integer; : begin : writeln('How old are you (type ''N'' if you don''t want to tell)? '); skipBlanks(input); if input^ in ['0'..'9','N','n'] then case input^ of '0'..'9' : begin read(age); ... end; 'N','n' : writeln('OK - just keep it a secret!') end else writeln('I assume you don''t want to tell me anyway.'); : end. Note how I can rely on the built-in 'read' procedure to convert the text-string to integers when reading 'age', without having problems with the non-numeric reply alternative. To do the equivalent without get/put would require 'skipBlanks' to return the character it stopped reading (as noted by Scott Schwartz <schwartz@shire.cs.psu.edu>), and would force me to write my own 'readIntegerFromACharacterVariableAndTextFile' procedure. Magne
grimesg@magic (George Grimes) (07/14/89)
In article <20239@adm.BRL.MIL> RDK%vm.temple.edu@cunyvm.cuny.edu (Robert Keiser) writes: >ok, I've been watching the current disscusion about read/write vs. get/put >and I have a question. But first, let me tell you where I'm coming from. >I've worked on a Cyber using U. of M. Pascal and on pc's using Turbo. On >the Cyber's, to get interactive I/O to work correctly required you to first >declare the file input to be interactive (by placing a '/' after the filename >on the program statement (i.e. PROGRAM HELLO (INPUT/,OUTPUT);). The slash >tells Pascal not to do the initial GET on input. Then to read anything, you >first would have to issue a blank readln followed by your read. The code >would look something like this: > . Example deleted >and I wanted to be realistic. Anyway, the question, what would the same code >look like in say VAX Pascal or MS Pascal? More stuff deleted > >Robert Keiser I tried the following in Vax Pascal: program(input,output); var name : varying[50]; begin write('What is your name? : '); readlne(name); writeln; writeln('The name you entered was: ',name) end. It compiled and ran without error. George ----------------------------------------------------------------------------- DOMAIN: grimesg@sj.ate.slb.com | George Grimes UUCP: {decwrl,uunet}!sjsca4!grimesg | Schlumberger Technologies INTERNET: grimesg%sjs@sdr.slb.com | 840 Avenue F #108 PHONE: (214)422-7200 | Plano, Tx. 75074 ----------------------------------------------------------------------------- Dis-claimer(as opposed to dat-claimer): If my employers knew that I had an opinion, they probably wouldn't approve of the opinion or the fact that I had it. -----------------------------------------------------------------------------
stuart@bms-at.UUCP (Stuart Gathman) (07/15/89)
In article <8736@pyr.gatech.EDU>, gus@pyr.gatech.EDU (gus Baird) writes: > No! There's a TREMENDOUS difference between > repeat > read(FileVar,ch) > until ch {is whatever}; > and > while FileVar^ {is not whatever} do > get(input); > The point is that that the version with read consumes the character > that stops the loop. This means that the routine after the skiptill So in one case the terminating char is in "Filevar^", and in the other case it is in "ch". Big deal. while FileVar^ {is not whatever) do get(input); is just var FileVar: ^byte; read(input,FileVar^); . . . while FileVar^ { ... } do read(input,FileVar^); If pascal had macros, you could either in terms of the other. The pointer stuff is a bother. The file variable stuff is just a convention as to where your one character read ahead is kept. Using "ch" as a convention is just as good as using "FileVar^", and more efficient to boot. (I prefer "unget(ch)" myself :-) BTW, Shouldn't "get(input)" be "get(FileVar)"? In that case get and put are even more braindamaged with such an inconsistent use of pointer notation. They could still be macros, however. FileVar would be #define FileVar F.buf { excuse me } and get could find the 'F' record address from the pointer address. -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
schwartz@shire.cs.psu.edu (Scott Schwartz) (07/15/89)
In article <168@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: | So in one case the terminating char is in "Filevar^", and in the | other case it is in "ch". Big deal. It is a big deal if "ch" is out of scope for whoever wants that character, yes/no? YES. | If pascal had macros, you could either in terms of the other. I doubt it. I've seen lots of people get exactly this construction wrong in C using macros. No more on this topic or I call the thought police. :-) | The pointer | stuff is a bother. The file variable stuff is just a convention as | to where your one character read ahead is kept. Using "ch" as a convention | is just as good as using "FileVar^", and more efficient to boot. What "pointer stuff" are you bothered by, and why? BY DEFINITION read (File, ch) MEANS begin ch := File^; get (File) end Care to explain HOW "ch" can be "more efficient" than "FileVar^"? It just ain't so. Also, "using 'ch' as a convention" is inferior from a software engineering standpoint (if nothing else) since now you are committed to having a global variable float around maintaining state for everyone. | (I prefer "unget(ch)" myself :-) Oops. Wrong newsgroup. :-) | BTW, Shouldn't "get(input)" be "get(FileVar)"? Yes. The posting you quoted had a typo. | In that case get and put | are even more braindamaged with such an inconsistent use of pointer notation. Could you explain that? Get is a procedure that takes a pointer to some hidden structure and modifies that structure. Seems consistent to me. -- Scott Schwartz <schwartz@shire.cs.psu.edu>