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!harpo!floyd!cmcl2!csd1!condict
From: condict@csd1.UUCP (Michael Condict)
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <110@csd1.UUCP>
Date: Mon, 29-Aug-83 22:31:31 EDT
Article-I.D.: csd1.110
Posted: Mon Aug 29 22:31:31 1983
Date-Received: Tue, 30-Aug-83 23:03:59 EDT
References: <666@mit-eddie.UUCP>
Organization: New York University
Lines: 77

Now I am genuinely confused.  I've heard these statements before that C does
not have I/O built into it and how wonderful this is, and I've never been
able to understand them.  People claim it improves portability, so I guess
that's why they find it wonderful, and who can disparage the goal of
portability?  The only problem I have with these claims is that I can't see
any reasonable view of C or programming languages in general under which they
are not obviously false!  Let me elaborate (and you can't stop me from there
anyway, can you?):

DEFINITION 1. Input/Output (I/O).  The means by which data is transferred
between an executing computer program and the rest of the world.

THEOREM 1.  A programming language without any way of doing I/O is of purely
theoretical interest.

PROOF.  Directly from the definition of I/O, since anything that is computed
by a program in the language cannot ever be discovered except by redoing the
calculations by hand, which clearly is not practical.

THEOREM 2.  C has I/O.

PROOF.  We could prove this by contradiction of theorem 1, using the fact that
people really do execute C programs on computers, so it is apparently not just
of theoretical interest.  A more direct approach is to note that to whatever
extent C is a language defined independently of any particular implementation,
it is a language that has several I/O constructs.  I'm not familiar with all of
them but I know that printf is one of them [K&R 1978].  Conversely, to whatever
extent C is a family of languages, say, a different one for each C compiler,
it is a safe bet that each member of the family has I/O.  For instance, on
any Unix implementation of C, the primitive I/O constructs are read,
write, open, creat and a few others.  Printf, scanf, getc and so on are all
definable in terms of these system calls.

Now let's look at portability:

THEOREM 3.  Let X be a language without I/O.  If any particular compiler for X
is to be useful, a set of I/O constructs must be added to the language processed
by the compiler. That is, the compiler must process a language different from X.

PROOF.  Directly from Theorem 1.  The fact that the only addition to X consists
of adding some library routines, rather than new syntax, is not relevant --
that these routines are guaranteed by the local reference manual to be available
makes them part of the local language.

THEOREM 4.  Let X be a language without I/O.  Complete, portable programs that
are useful cannot be written in X.

PROOF.  By theorem 3, we know that every particular implementation of X will
have its own set of I/O constructs.  And to whatever extent each implementation
of X has the same set of I/O constructs, X is not a language without I/O, (or
at least the informally defined extension to X that everybody is implementing
and using is not a language without I/O).  So we are forced to conclude that
there are several different ways of doing I/O depending on which compiler
is in use.  Hence, useful X programs, since they perform I/O, must be changed
when moved from one compiler to the next.

All facetiousness aside, would somebody please show me where my reasoning
has gone astray here?  My best guess as to why people say that C has no I/O is
that all its I/O is performed with function calls, but I can't see how there
being no separate syntax for the I/O constructs matters one hill of beans.
We certainly don't say that FORTRAN has addition but does not have the absolute
value operation simply because the latter is a function call while the former
uses infix notation; or do we?  As far as the portability issue goes, we've
already had one response arguing from bitter experience against the
portability of C, so I don't feel quite as badly admitting that I haven't the
foggiest idea how you support this view (and usually I can anticipate the
other side of a debate to some extent).  Laura, can you help me out here, since
you are one of the people who subscribe to these views?

REFERENCE.
Kernighan B. & Ritchie D, "The C Programming Language", Prentice-Hall, 1978.

Michael Condict		...!cmcl2!csd1!condict
Courant Inst., N.Y.U.
251 Mercer St.
New York, N.Y.  10012