Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!ns-mx!pyrite.cs.uiowa.edu
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: comp.lang.pascal
Subject: Re: (IBM RS-6000 Pascal) lazy I/O
Message-ID: <5947@ns-mx.uiowa.edu>
Date: 7 May 91 23:22:14 GMT
Article-I.D.: ns-mx.5947
References: <14777@ccncsu.ColoState.EDU>
Sender: news@ns-mx.uiowa.edu
Distribution: world,comp
Lines: 41

From article <14777@ccncsu.ColoState.EDU>, by mglacy@lamar.ColoState.EDU:
>
> What is "Lazy I/O?"

Lazy I/O is the "industry standard" way of implementing the Pascal "get"
operation when taking input from an interactive source.  If all you do is
use readln to pick up entire lines, you won't notice it.  If all
you do is use some nice (but nonstandard) window interface, you won't
notice it either.

The problem shows up because Wirth, for whatever reason, decided that, for
file variable f, f^ should point to the current character from that file,
and get(f) should advance the current character.  As a result, a naive
implementation of Pascal requires that the first character of input to a
program be typed before the program begins execution, and it requires that
the first character of the next line be typed before a readln can consume
the end-of-line marker on the previous line.

Any Pascal that doesn't have lazy I/O will have the above kinds of problems.

The lazy I/O solution was worked out some time ago (like in the mid 1970's).

The name lazy I/O comes from the fact that the underlying primitive read
operations aren't necessarily done when the user calls get; instead, they
are done later, when the user actually inspects the character gotten by get.

As I remember the details of what eventually emerged as a "standard",
you need a hidden boolean associated with each interactive text file.  When
true, f^ is a valid pointer to the current character.  When false, f^ is
not valid.  Initially, this boolean is false, and after an call to get, it
is false again because the next character need not yet have been typed.  All
operations that inspect f^, including the implicit test of f^ made by eoln,
are preceeded by a test of this boolean, and if it is false, the operation
performs the necessary primitive read operation to actually get the character.

The execution overhead of this scheme is small compared to the actual
interactive I/O operation, and the result behaves in a surprisingly intuitive
manner, given the far-from-intuitive structure of Pascal's file variables and
the put and get operations.
					Doug Jones
					jones@cs.uiowa.edu