vinson@oddjob.UChicago.EDU (Michael Vinson) (02/24/88)
I am using Sun UNIX Pascal, and I have a problem that is annoying in
the extreme. The problem is as simple as it is absurd: when I try to
compile a program that read a string (i.e. a packed array of char) from
a text (yes text) file, the compiler tells me "Can't read strings from
a text file"!!! This is crazy. It means, for example the the following
lines won't work:
var FileName : packed array[1..80] of char;
...
write('Enter file name: ');
readln(FileName);
This is a pain in the *ss! Does anyone have any ideas/solutions/remedies?
(I mean, I can always read in a string one char at a time, but I shouldn't
have to. If you can't read strings from a text file, which includes standard
input, what can you read them from?)
Michael Vinsondjones@megatest.UUCP (Dave Jones) (02/26/88)
in article <14411@oddjob.UChicago.EDU>, vinson@oddjob.UChicago.EDU (Michael Vinson) says: > > I am using Sun UNIX Pascal, and I have a problem that is annoying in > the extreme. The problem is as simple as it is absurd: when I try to > compile a program that read a string (i.e. a packed array of char) from > a text (yes text) file, the compiler tells me "Can't read strings from > a text file"!!! This is crazy. It means, for example the the following > lines won't work: > > var FileName : packed array[1..80] of char; > ... > write('Enter file name: '); > readln(FileName); > > This is a pain in the *ss! Does anyone have any ideas/solutions/remedies? > (I mean, I can always read in a string one char at a time, but I shouldn't > have to. If you can't read strings from a text file, which includes standard > input, what can you read them from?) > > Michael Vinson Quit your whining, for Pete's sake. You kids got it so easy today. Back in '71 I once had to read an intire string ONE BIT AT A TIME. I was exhausted for a week. Now go write that GetString procedure. And don't be so hard on Niklaus Wirth. He meant well. He just didn't know any better. I'm sure he's just sick about this whole conformant array thing. Yours truly, Richard M. Nixon
ags@s.cc.purdue.edu (Dave Seaman) (02/26/88)
In article <14411@oddjob.UChicago.EDU> vinson@oddjob.uchicago.edu (Michael Vinson) writes: >I am using Sun UNIX Pascal, and I have a problem that is annoying in >the extreme. The problem is as simple as it is absurd: when I try to >compile a program that read a string (i.e. a packed array of char) from >a text (yes text) file, the compiler tells me "Can't read strings from >a text file"!!! This is crazy. It means, for example the the following >lines won't work: [code deleted] That is correct. Reading strings from a text file is not allowed in standard Pascal. Many implementations provide a way to do it, but it is not part of the standard. >This is a pain in the *ss! Does anyone have any ideas/solutions/remedies? Sure. Write a short procedure to do what you want, and call it as needed, or use a language/implementation that supports string input directly. >(I mean, I can always read in a string one char at a time, but I shouldn't >have to. If you can't read strings from a text file, which includes standard >input, what can you read them from?) You can read strings from a file of strings. type string = packed array [1..80] of char; var f : file of string; str : string; begin reset(f); read(f,str); . . . -- Dave Seaman ags@j.cc.purdue.edu
abcscnuk@csuna.UUCP (Naoto Kimura) (02/27/88)
In article <14411@oddjob.UChicago.EDU> vinson@oddjob.uchicago.edu (Michael Vinson) writes: >I am using Sun UNIX Pascal, and I have a problem that is annoying in >the extreme. The problem is as simple as it is absurd: when I try to >compile a program that read a string (i.e. a packed array of char) from >a text (yes text) file, the compiler tells me "Can't read strings from >a text file"!!! This is crazy. It means, for example the the following >lines won't work: There's nothing wrong with your compiler. You can't read strings from a text file. >... >This is a pain in the *ss! Does anyone have any ideas/solutions/remedies? >(I mean, I can always read in a string one char at a time, but I shouldn't >have to. But you have to... in standard pascal that is >If you can't read strings from a text file, which includes standard >input, what can you read them from?) > >Michael Vinson You *might* be able to read strings (declared as packed array of char) from a file of the string type, though you might get some pretty weird stuff if the file is not of a fixed-format type. You should also make sure that you use "flush" (if there is such a procedure in the pascal you use) after using a "write" to output your prompt, otherwise your prompt may not appear before it waits for input. What's really fun is when your prompt appears in the middle of typing your response (this happens with the Berkeley compliler "pc" when you forget to use "flush" after writing out the prompt. If you use writeln, usually there is no problem). You may still get some problems, especially if you use "eof" or "eoln" before your write, because the computer will wait for a character (to check for eof or eoln) then do the write, sometimes, the implicit get at the beginning will cause this strange behavior. There aren't any problems like this when you run the program as a batch job. //-n-\\ Naoto Kimura _____---=======---_____ (csun!csuna!abcscnuk) ====____\ /.. ..\ /____==== // ---\__O__/--- \\ Enterprise... Surrender or we'll \_\ /_/ send back your *&^$% tribbles !! P.S.: If you ever wonder why eoln and eof exist, try using a CDC. Eoln is signaled by two zero bytes aligned at a word boundary. A zero byte happens to be a colon character.
gvcormack@watdragon.waterloo.edu (Gordon V. Cormack) (02/28/88)
In article <290@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: > Now go write that GetString procedure. And don't be so hard on Niklaus Wirth. > He meant well. He just didn't know any better. I'm sure he's just > sick about this whole conformant array thing. > > > Yours truly, > > Richard M. Nixon I wish it were true "he didn't know any better". In fact, he designed Algol W long before Pascal, and Algol W is better in almost every respect. (In fact the only really brain-damaged aspect of Pascal that has its roots in Algol W is the relative priorities of comparison (<, >, <=, etc.) and boolean (and, or) operations). -- Gordon V. Cormack CS Dept, University of Waterloo, Canada N2L 3G1 gvcormack@waterloo { .CSNET or .CDN or .EDU } gvcormack@water { UUCP or BITNET }
victor@cs.vu.nl (L. Victor Allis) (02/29/88)
In article <14411@oddjob.UChicago.EDU> vinson@oddjob.uchicago.edu (Michael Vinson) writes: >The problem is as simple as it is absurd: when I try to >compile a program that read a string (i.e. a packed array of char) from >a text (yes text) file, the compiler tells me "Can't read strings from >a text file"!!! This is crazy. > >This is a pain in the *ss! Does anyone have any ideas/solutions/remedies? > >Michael Vinson In ISO-Pascal, reading a string is not possible. This is one of ISO-Pascal's bad sides (another one is the impossibility to work with random access files). Most commercial Pascal implementations I've seen provided extra string functions, but you must know that these are only extra's. So you better find yourself a Pascal implementation you like more, or you write a nice procedure ReadString, which does the thing you want, like: --------------- procedure ReadString(var f : text; var String : packed array[Low .. Up: integer] of char); var i : integer; begin for i := Low to Up do if not eoln(f) then read(f, String[i]) end; --------------- I did not test this (just wrote it as example). It should work on a Level 1 implementation of Pascal. Victor Allis. Vrije Universiteit van Amsterdam. The Netherlands.
jjs%mykeiko@Sun.COM (James Simon) (03/03/88)
In article <14411@oddjob.UChicago.EDU> vinson@oddjob.uchicago.edu (Michael Vinson) writes: >I am using Sun UNIX Pascal, and I have a problem that is annoying in >the extreme. The problem is as simple as it is absurd: when I try to >compile a program that read a string (i.e. a packed array of char) from >a text (yes text) file, the compiler tells me "Can't read strings from >a text file"!!! This is crazy. It means, for example the the following >lines won't work: > >var FileName : packed array[1..80] of char; >... >write('Enter file name: '); >readln(FileName); > >This is a pain in the *ss! Does anyone have any ideas/solutions/remedies? >(I mean, I can always read in a string one char at a time, but I shouldn't >have to. If you can't read strings from a text file, which includes standard >input, what can you read them from?) > >Michael Vinson This problem/feature has been fixed. I don't know what to say other than that in the Pascal 1.1 realease I/O is better. James Simon
djones@megatest.UUCP (Dave Jones) (03/07/88)
in article <43904@sun.uucp>, jjs%mykeiko@Sun.COM (James Simon) says: > > In article <14411@oddjob.UChicago.EDU> vinson@oddjob.uchicago.edu (Michael Vinson) writes: ... >>var FileName : packed array[1..80] of char; >>... >>write('Enter file name: '); >>readln(FileName); >> [ It gives a compile-error. ] >> >>Michael Vinson > > This problem/feature has been fixed. I don't know what to say > other than that in the Pascal 1.1 realease I/O is better. > > James Simon Reading strings with a readln in Pascal is not a standard feature. I am not in the habit of defending Pascal, expecially its I/O, but I can see why it is not a feature: What is a string? The entrie file? The next 80 chars in the file? The characters up to the next white-space char? Up to the next line-end? Should the string-variable be null-terminated or blank-filled? If you use readln on a string, and it compiles, the implemnetation may not be portable to other systems, even if they have 'fixed the problem/feature.' But then, all this is not really too important is it? Just write the dad-gum GetString procedure. Dave J.
vinson@oddjob.UChicago.EDU (Michael Vinson) (03/07/88)
In article <301@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: > >Reading strings with a readln in Pascal is not a standard feature. I am >not in the habit of defending Pascal, expecially its I/O, but I can see >why it is not a feature: What is a string? The entrie file? The next >80 chars in the file? The characters up to the next white-space char? >Up to the next line-end? Should the string-variable be null-terminated >or blank-filled? This question is easily answered. A string is a sequence of characters terminated by an eoln. Thus one can writeln a string (which is, I believe, allowed in standard Pascal), and subsequently readln the same string. This sort of symmetry is always desirable; any time you write something, there should be an analogous way to read it. >But then, all this is not really too important is it? >Just write the dad-gum GetString procedure. Yeah yeah. The problem then is that you either have to include the file var explicitly, as in procedure GetString(var FileVar : text; var TheString : string); in which case you have to call GetString(input,MyString) to read from standard input (the keyboard), or else you need two separate procedures, one for reading the keyboard, one for reading from a file. Either "solution" is still annoying (I've chosen the former). I realize this whole thing is kind of a minor point, but it is a nuisance (especially after getting used to something like TP, which is far more reasonable (but of course non standard) in its approach to I/O). Michael Vinson
djones@megatest.UUCP (Dave Jones) (03/09/88)
in article <14461@oddjob.UChicago.EDU>, vinson@oddjob.UChicago.EDU (Michael Vinson) says: > > In article <301@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >> >>Reading strings with a readln in Pascal is not a standard feature. I am >>not in the habit of defending Pascal, especially its I/O, but I can see >>why it is not a feature: What is a string? The entire file? The next >>80 chars in the file? The characters up to the next white-space char? >>Up to the next line-end? Should the string-variable be null-terminated >>or blank-filled? > > This question is easily answered. A string is a sequence of characters > terminated by an eoln. Thus one can writeln a string (which is, I believe, > allowed in standard Pascal), and subsequently readln the same string. This > sort of symmetry is always desirable; any time you write something, there ^^^^^^^^ ^^^^^^^^^ > should be an analogous way to read it. > Sorry, but I'm going to have to mark you down a whole letter grade for this answer. You obviously have not read the assignment. You didn't even attempt to answer the part about blank-filling when the string you read is shorter than 80 chars. And I can't even give you partial credit for the part you did answer. Sorry. Consider this: You can "write" a string and no line-end will go to the output file. It's that "ln" suffix that does the trick. But if you only write it, without the "ln", then try to "read" the string, where's your symmetry? Notice that the character representation of floating point numbers is not necessarily terminated by an eoln, but you can writeln them, then readln them, as well as write then the read them. The desirable symmetry would fill your heart with boyish delight. For your info, "writeln(foo)" just means, "write(foo); writeln;". That's all. And "readln(foo)" is defined to mean "read(foo); readln". And you know what "readln" does? Way down there in the mysterious runtime support library? Here it is, dusted off and exposed to the light of day: READLN(curfile) register struct iorec* curfile; { while(!TEOLN(curfile)) GET(curfile); GET(curfile); } Yep. It just throws away the input up to and including the next new-line character. Whoopty-do. >>But then, all this is not really too important is it? >>Just write the dad-gum GetString procedure. > > Yeah yeah. The problem then is that you either have to include the file > var explicitly, as in > > procedure GetString(var FileVar : text; var TheString : string); > > in which case you have to call GetString(input,MyString) to read from > standard input (the keyboard), or else you need two separate > procedures, one for reading the keyboard, one for reading from a file. > Either "solution" is still annoying (I've chosen the former). ^^^^^^^^ > I realize this whole thing is kind of a minor point, but it is a nuisance ^^^^^^^^ > (especially after getting used to something like TP, which is far more > reasonable (but of course non standard) in its approach to I/O). > You are far too easily annoyed. Try getting more exercise. Get some walking in. Are you getting enough roughage? [His demeanor suddenly changes to one of aggression as he peers intently into the emacs buffer.] You want to know what's annoying? I'LL TELL YOU what's annoying. Annoying ISN'T when you get your first job out of school, and it's writing runtime support routines for two Pascal systems. And you argue with the standards committee about what "mod" means, and you WIN, but then you decide you argued on the wrong side. ANNOYING? Hardly! Then after a few years of Pascaling, you get a visiting professorship at a major university. Then, only then, they tell you that you HAVE to use Pascal in all of you courses, even the graduate courses. You want to hear ANNOYING? That's nothing. NOTHING!! You leave that job for a balmy position in sunny California. Doing what? Do you really have to ask? And after three and a half years basking on the beach and hacking, you have to write a new compiler for -- shall I say it? -- the "P" word. And all along... All this time... ten long years... you think Pascal is just plain silly!! Is THAT annoying? NO! THAT'S not annoying. [Pounds the table with his fist and looks up like Brother Theodore.] What's ANNOYING is that for all this time, you've been the one that people send people to with a "Pascal question". It's worse than being in the office right next to the Telex machine, and people know that you know how to use it. [He collapses on the keyboard, a totally spent ghostly shell of his former cheery good looks and suave wisdom.] kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkllllllk;k [Trying, unsucessfuly, to look composed, he raises his head and smiles weakly.] Gotta run now. There's this GetString procedure I've been meaning to write. Dave Jones Megatest Corp. 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA Ban the smiley.
djones@megatest.UUCP (Dave Jones) (03/10/88)
I wish to apologise to anyone who may have found my postings about this subject to be offensive. I just received a singularly vitriolic email letter about my postings, and it caught me completely off guard. It made me think about the style of the postings, and why I thought they were funny, when obviously at least one other person found them to be anything but funny. I used to be a pretty uptight individual. Then some things happened that shook me out of it. I will not go into the details, which are personal. But, you know how reformed drunks will preach at you if you get loaded? And how reformed smokers act around smoke? Well I guess I am a little bit that way when I perceive that I observe someone getting upset over triffles. Here's what I have just now come to realize: I want to say, "Hey lighten up!" But saying that can have the exact opposite effect from what you want it to. So I have developed a reaction which is a parody on my old behavior. When I get in that preachy mode, I'm not ridiculing the person I am speaking to. I am making fun of the very act of being serious and preachy. As is obvious now, the style of humor does not translate well into network traffic. I guess the problem is that regardless of how absurd the speach may be -- and I thought I laid it on pretty thick -- it isn't clear to every listener that the speaker is not serious, unless the listener knows the speaker well enough to know that the speaker himself knows that the diatribe is absurd. Dave Jones 880 Fox Lane San Jose, CA. 95131 (408) 437-9700 Ext 3227 UUCP: ucbvax!sun!megatest!djones ARPA: megatest!djones@riacs.ARPA