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: <112@csd1.UUCP>
Date: Tue, 30-Aug-83 21:38:54 EDT
Article-I.D.: csd1.112
Posted: Tue Aug 30 21:38:54 1983
Date-Received: Thu, 1-Sep-83 00:58:48 EDT
References: <678@mit-eddie.UUCP>
Organization: New York University
Lines: 51

Boy, this is getting rough -- people are starting to talk about breaking each
other with clubs!  Not to bring down such mayhem on my own poor head, I would
just like to reiterate a point that was also made by at least one of my allies.
Perhaps I can avoid all attempts at cuteness this time and confine myself to
the facts (but I doubt it).  The issue that seems to be most widely disagreed
upon is whether or not C has I/O.  When I referred to K&R I did not mean to
plant myself in the camp of the faithful Bible thumpers who take everything
found there as divinely inspired, hence unarguable.  I only meant to point to
the source most influential in the design of C I/O as it exists today.

I don't particularly find it important whether the book says that I/O is
part of C or not or shows printf in the syntax summary.  In fact, there
happens to be absolutely no mention of I/O, even of its omission, in the
C Reference Manual (the "official" language-defining portion of the C book).
All of this is irrelevant, because a language is defined by its use, not its
official definition -- this is true of English and is just as true of program-
ming languages (even Ada). One person called this the "language together with
its environment", but I don't see how to make such a distinction.  The language
consists of those sequences of symbols you can write down with reasonable
confidence about their meaning.  For a programming language with dozens of
different compilers running on thousands of different computers, each with
its own support library, there is no hard and fast definition of what is in
the language and what is not.  All the same it is just as clear that printf is
in the C language as, say, the union type, since more implementations
probably provide the former than the latter.

Anyway, let's not argue about trivial semantic issues like this.  I'll
agree to say that C has no I/O if you'll agree that there is a certain extended
language, let's call it C+, that everyone uses instead of C and that does have
I/O.  See, we're both right!

What I'd really like to see is a resumption of the discussion about
improving the way I/O is handled in programming languages; that is, not whether
C has I/O (every implementation will), but what is the best way to connect
a high-level language, especially one oriented towards very abstract program-
ming, such as SETL, LISP or PROLOG, to the grungy, incredibly over-designed and
horribly complex I/O monster found on typical operating systems.  One popular
point of view seems to be that the official language definition should avoid
the I/O issue entirely, presumably allowing individual implementations to
define this necessary portion of the language by default.  The claim is that
this leads to portability of programs.  I'm still waiting for an explanation
of the reasoning behind this conclusion, which I am at a loss to reproduce.
Even if you convince me that this is the right way to go, a possibility I have
not ruled out at all, we don't seem to have made any progress on the original
problem, which is how to define the I/O portion of programming language.
You've just told me WHO should do it (the compiler writers, rather than the
language designer) rather than HOW it should be done.


Michael Condict		...!cmcl2!csd1!condict
Courant Inst., N.Y.U.