Path: utzoo!mnetor!uunet!husc6!hao!oddjob!vinson
From: vinson@oddjob.UChicago.EDU (Michael Vinson)
Newsgroups: comp.lang.pascal
Subject: Re: Sun Pascal bug?
Message-ID: <14461@oddjob.UChicago.EDU>
Date: 7 Mar 88 14:56:27 GMT
References: <43904@sun.uucp> <301@goofy.megatest.UUCP>
Reply-To: vinson@oddjob.uchicago.edu (Michael Vinson)
Organization: The James Franck Institute
Lines: 32

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