Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!cca!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.lang
Subject: Re: I/O operations in programming langua - (nf)
Message-ID: <382@ima.UUCP>
Date: Fri, 26-Aug-83 18:36:28 EDT
Article-I.D.: ima.382
Posted: Fri Aug 26 18:36:28 1983
Date-Received: Mon, 29-Aug-83 01:02:13 EDT
Lines: 50

#R:csd1:-10800:ima:30100002:000:2822
ima!johnl    Aug 26 11:38:00 1983

The matter at hand is why file access shouldn't look just like variable
access, with some reference to Pascal.

Pascal's I/O is certainly a pain, largely because it was designed with card
readers in mind.  But to answer the question, there are languages which do
make file access and variable access look the same.  Snobol comes to mind,
in which every time you fetch the variable INPUT (or SYSPIT in the old days)
it gets a record from the input, when you assign something to OUTPUT it goes
to the output, and there are functions to associate variables with files.
Grody old RSTS Basic-Plus has a virtual array feature that lets you treat a
disk file just like an array.  Various forms of APL have a "shared variable"
feature that associates variables with all sorts of outside things including
files.  Unfortunately, all of these schemes stink.

The problem is that file I/O is more complicated than reading and writing
variables.  The data in files is often much more complex than anything you'd
keep in a single structure in memory.  Try writing a variant record
structure that describes a Unix archive file as seen by the linker, keeping
in mind that some archive members are in a.out format and some aren't.  You
could probably do it, but the structure would be so grotesque as to be
useless.  Once you're done that, fit files with multiple key structures into
your framework.  Then throw in line printers, bit map terminals, and HDLC
X.25 ports.  Remember that you have to deal with time-outs, end of file
conditions, and I/O errors.

One might say "then don't use such complicated file structures," but the job
of any program that does I/O is to deal with some a priori structure.  (If
the program only writes data that only it can read, it's not likely to be
very useful, is it?) Snobol and APL programs cannot generally read files
not made of plain old lines of text (or in the APL case, of funny APL
objects.)

As far as portabilty goes, experience shows that programs written in rotten
old Cobol* port amazingly well (a lot better than Fortran or Pascal) because
the I/O model, although complex, is well specified and complete.  It deals
quite adequately with variable length records of different sizes, indexed
files, and all that stuff.  C language I/O also ports reasonably well,
although to be fair it usually is moving along with a Unix environment, and
few C programs do really complicated I/O like some Cobol programs do.

John Levine, decvax!yale-co!ima!johnl, ucbvax!cbosgd!ima!johnl,
{allegra|floyd|amd70}!ima!johnl, Levine@YALE.ARPA

* - I'm not claiming that Cobol is the best thing around for expressing
algorithms or whipping up little programs, just that the I/O model is much
better thought out than in many more "modern" languages which follow the
Algol tradition and punt.  Save your flames.