Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site csd1.UUCP
Path: utzoo!linus!decvax!microsoft!uw-beaver!cornell!vax135!floyd!cmcl2!csd1!condict
From: condict@csd1.UUCP (Michael Condict)
Newsgroups: net.lang
Subject: Re: I/O operations in programming langua - (nf)
Message-ID: <109@csd1.UUCP>
Date: Sun, 28-Aug-83 15:55:04 EDT
Article-I.D.: csd1.109
Posted: Sun Aug 28 15:55:04 1983
Date-Received: Mon, 29-Aug-83 14:23:34 EDT
References: <382@ima.UUCP>
Organization: New York University
Lines: 87

I wish I could say that I am genuinely surprised at the negative responses
to my proposal for unifying files with other variables, but that would
be disingenuous.  The course of evolution of programming languages and
storage technologies has made it almost inevitable that our thinking about
the simplest ways to describe the manipulation of data be distorted.  In any
case, it is clear that I have to some extent been misunderstood.

I'll try to individually address most of the objections that have been raised
so far, but first, just to be pedantic, let us prove the following

THEOREM 1.  If the contents of (or operations on) a file or device are not
adequately modelled by the variable declarations and operations of C (or
Pascal) then they are not adequately modelled by viewing the file or device
as an array of bytes, as is required in the Unix I/O model.

PROOF.  Both C and Pascal have the array of bytes (chars) in their repertoire
of data structures.  If you want to get picky and insist that a file cursor
position be remembered, the array can be paired with an integer in a record.

COROLLARY 2.  It is at least as easy to program any operation on any file or
device in$!language where files are unified with variables as it is in a
language where they are required to conform to the Unix I/O model.

Armed with these results, I am ready to tackle the objections:

Objection 1: Files and devices are much too complicated, and their desired
time behaviour too critical and too dependent on geometry of storage devices
for them to be dealt with as programming variables.

Response: For the first part, refer to Corollary 2.  For the second, I
claim that questions of track and cylinder locations and rotational speeds
are diminishing in importance and certainly are not factors that are considered
"more often than not" in the typical application program, even data-base
applications -- rather such concerns are more often entrusted to the operating
system.  In future technologies, e.g. bubbly memory, optical disks and the
disappearance of sequential magnetic tapes, such concerns will fade away.
Even if they don't, there are people working hard right now on the problem of
expressing such time-critical behaviour in the emerging family of real-time
programming languages.

Objection 2: I don't want the C compiler gunked up with knowledge of all sorts
of little-used devices and data structures for talking to them.  This would
ruin portability of the compiler because it would have to be changed on each
machine.

Response: I'm not proposing that the C compiler or any other compiler know how
to translate the use of variant records into commands for a McDoogle's
french-fries computer or whatever.  The idea would be for the compiler to know
how to translate variable declarations and operations into a fixed I/O model,
either the one that is presented to it by its local operating system, or an
abstract one that is more general, if it is to be a portable compiler.  On
a Unix system this would amount to it knowing how to compile such operations
into the reading and writing of chunks of storage that are accessed by an
integer address (the file cursor).  It already knows how to do this; only the
names of the instructions that it generates would have to be changed.  And
this connection to the I/O model of the operating system must be made in any
case; the only question is the most elegant way to do it.  As far as the
programming of exotic devices is concerned, that would be a matter for the
programmer and the operating system to negotiate through the restrictions of
the I/O model, as it is now.  The role of the compiler would just be to give
the programmer a high-level, elegant interface to this model.

Objection 3: SNOBOL and APL implement your proposal and the results are not
satisfactory.

Response: SNOBOL, at least, is farther from my proposal than is Pascal.  In
SNOBOL, input must be viewed as a sequence of lines, whereas in Pascal it is
a sequence of arbitrary data.  I am unfamiliar with APL shared variables, but
my limited knowledge of them is that they are much like what I am proposing.
Unfortunately, as you point out, the data structures of APL are a bit
restricted, even strange, compared to languages like Pascal and C.  This is
an argument for generalizing the data structures of APL, not an argument against
my proposal (and, again, several people have proposed extending APL to allow
more general data structures than the n-dimensional array, e.g. Goeff Lowney
here at N.Y.U.).  Alongside this objection the author mentioned that he
approved of the way I/O is done in Cobol, because it is complete and precisely
defined.  I mostly agree, but see no reason that this completeness and precision
would be lost if I/O were to be merged with variables in Cobol (in fact it
partly is, to the extent that the same sort of nested record declarations
can be made to describe files or program variables).


Michael Condict		...!csd1!condict
Courant Inst., NYU
251 Mercer St.
New York, NY   10012