Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rochester!ritcv!mjl
From: mjl@ritcv.UUCP (Mike Lutz)
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <497@ritcv.UUCP>
Date: Thu, 1-Sep-83 18:19:11 EDT
Article-I.D.: ritcv.497
Posted: Thu Sep  1 18:19:11 1983
Date-Received: Sat, 3-Sep-83 04:26:26 EDT
References: utcsstat.976
Lines: 35

Here I go off on a vacation for a couple of days and things really
light up (or heat up).  Anyhow, having perused the 30-odd articles,
some odder than others, on the subject of I/O, C, and UTOPIA84 (the
language that solves everybody's problems), I will add my two cents.

It is a red-herring to ask whether or not C has I/O -- of course it
does.  However, the real issue (and one which few have addressed
directly) is the manner in which I/O is specified.  As Dennis Ritchie
says, C separates the language issues from the particular form in which
I/O is expressed in the language.  In this way, new I/O packages can be
tried out without jeopardizing existing programs that use previous
packages.  What is more, as technology progresses, new I/O paradigms
can be included without sending all the compiler writers back to their
terminals to hack at LEX, YACC, and the code generators.

An example of a new paradigm is the curses library, providing a screen
oriented I/O interface:  a mode of I/O that was unknown (or at least
unusual) when C and Pascal were being developed.  Whereas the addition
of this new paradigm to C is relatively easy (just write new
functions), in Pascal it's a real pain.  The root cause of the problem
was hubris on the part of Pascal's designers, who decided in 1970 that
they "knew" how I/O should be modeled once and forever, and who instead
created a iron box which has imprisoned a generation of programmers.  I
bet dollars to donuts that a similar fate awaits those who "know" how
I/O should be implemented in 1983, and are willing to embed their ideas
in special linguistic forms.

So, though there definitely is I/O in C, the crucial point is the
manner in which it is incorporated.  The library function approach is a
source of power and flexibility, and my plea would be to build on this
protean base. The alternative is a procrustean I/O model (such as found
in most other languages).

Mike Lutz
{allegra,seismo}!rochester!ritcv!mjl