Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site pegasus.UUCP
Path: utzoo!linus!decvax!harpo!floyd!whuxlb!pyuxll!eisx!npoiv!npois!hogpc!pegasus!wilner
From: wilner@pegasus.UUCP
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <496@pegasus.UUCP>
Date: Fri, 26-Aug-83 13:15:54 EDT
Article-I.D.: pegasus.496
Posted: Fri Aug 26 13:15:54 1983
Date-Received: Sat, 27-Aug-83 22:51:01 EDT
References: <108@csd1.UUCP>
Organization: AT&T Information Systems, Lincroft NJ
Lines: 24

Michael Condict asks why there must be a separate set of consructs
for performing IO.  There need not be, but the answer is not to
mash files into arrays.  Devices exhibit a richer set of properties
than arrays (e.g., access time, cylinder organization, sequential
transfer).  More often that not, applications need some control over
these properties in order to run efficiently.

It seems highly desirable to have one basic declaration for what we
now call strings, arrays, files, pipes, and sequences.  Let's not
forget shell variables and command-line arguments while we're at it.
The invention that we'd all like is a unifying data type into which
we can read, write, index, search and do all the common things in a
common way, yet which continues to have time-dependent behavior and
to exhibit behavior that arises from the geometry of the hardware
out of which it is constructed.  As long as we can additionally
express such things as "block size" and number of buffers for these
new-fangled strings, we don't need files explicitly.  Finally, if
one's system has a swift implementation of these beasts that doesn't
use disk for the little ones and does use disk for the big ones,
everyone should be happy.

Languages are loath to admit time- and space-dependent behavior into
their data types, but if we are to unify arrays and files, some
compromise is necessary.