Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site fluke.UUCP
Path: utzoo!linus!decvax!microsoft!fluke!kurt
From: kurt@fluke.UUCP (Kurt Guntheroth)
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <691@vax2.fluke.UUCP>
Date: Fri, 2-Sep-83 18:26:00 EDT
Article-I.D.: vax2.691
Posted: Fri Sep  2 18:26:00 1983
Date-Received: Sun, 4-Sep-83 13:28:03 EDT
References: <1791@allegra.UUCP>
Organization: John Fluke Mfg. Co., Everett, Wash
Lines: 25

I/O in C/UNIX

When one talks about a language used almost exclusively on a single
operating system (C/UNIX), and which has a standard I/O package, you might
as well consider that I/O is built into the language.  In fact, 

I/O as part of the language

I have seen languages which defined I/O as part of the language and they are
usually ugly.  I am thinking in particular of the proposed ANSI BASIC which
has so many ways of doing the same thing to a file that it is impossible to
remember what functions work in what modes and with what results.

The real problem is that people have not spent enough time deciding what
operatinos are good things for operating systems to support.  In general
there is not a good model of a file that is usable by enough people.  UNIX
and C have chosen a model that is at least consistent (seekable byte
stream), but a little simple for many people and also a little non-portable
to systems with different size 'bytes'.

It would be nice if as much attention was devoted to formalisms for I/O and
operating systems as was devoted to formalisms for programming language
constructs.  Unfortunately, there really are people in acedemia who treat I/O as
unnecessarily dirty and 'real-world' and persue issues that can be theorized
about with more detachment.