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!gummo!whuxlb!floyd!cmcl2!csd1!condict
From: condict@csd1.UUCP (Michael Condict)
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <115@csd1.UUCP>
Date: Fri, 2-Sep-83 14:25:52 EDT
Article-I.D.: csd1.115
Posted: Fri Sep  2 14:25:52 1983
Date-Received: Sat, 3-Sep-83 07:30:18 EDT
References: utcsstat.976, <497@ritcv.UUCP>
Organization: New York University
Lines: 86

I hope that Mike Lutz has cleared the air about the issue of whether or not
C has I/O.  I feel a little guilty about prolonging the discussion, which is
of course a "red herring".  In my defense, I was trying to indicate the
undesirability of defining the boundaries of a programming language as "the
set of strings given meaning by the compiler alone, rather than any set of
object libraries, whether standard or local".  I was attempting to use the
Socratic method of posing questions that point out serious difficulties with
widely held beliefs.  Well it didn't work.  I guess Socrates was a little
better at it than I am.  So now I'll have to resort to the direct approach.
Why do I say this definition is undesirable?

Other than the fact that my C processor may not involve a separate compiler,
run-time system and object libraries, the problem that I was trying to expose
is evidenced by the early responses to my first notes.  People were expounding
the virtues of C not having any I/O, without any recognition at all of the
fact that this is only due to a technicality in their definition of what is in
the C language.  Most of these people would be quick to admit that there is
a fairly well defined set of C statements (almost all of them function calls)
that one can supply to almost any C processor to cause I/O to happen in a
predictable fashion.  Thus any advantages accruing to the C I/O paradigm are
not due to the fact that I/O is not defined anywhere in the collection of
documents, compilers and portable/standard object libraries that could be called
"informal C + environment".  Rather, as Dennis Ritchie and Mike Lutz point out
these advantages must occur because of *where* I/O is defined in C, namely
in the object libraries, rather than the compiler.  Now to the main point of
this note, the issue of whether such advantages actually do exist and why.

The claim appears to be that I/O is one portion of a programming language that
should not have separate syntax associated with it and be processed by the
compiler.  Of course, no one would argue that it should not have separate
semantics associated with it, otherwise it would not exist!  So we must
conclude that the only way this can happen is to steal from one of the other
constructs that do have syntax, in this case the function call.  That is, we
can arrange that certain function calls do I/O, instead of satisfying the
otherwise inviolable rule that the function call can be replaced by C code
that does the same thing.  This is perfectly acceptable, given that we
believe that I/O does not deserve its own syntax.  In fact, my proposal for
merging variables with files is almost the same approach.  I want to steal
from the syntax of variable declarations, using ones that were prefixed
with the "slow" attribute to perform I/O, at least to files (if not devices).
The reason I chose this approach is that, clearly, file I/O is a *data*
operation, not a matter of logic and control structures.  It therefore seems
most natural to use the data-oriented variable mechanisms of the programming
language to model I/O, rather than using the function call, which is
control-oriented.

The argument for using function calls was based on the belief that I/O is
somehow less well understood or more rapidly evolving than other portions of
programming languages and so, since compilers are more difficult to change than
object libraries, we should put the definition in the library rather than
in the syntax tables.  Furthermore, users can avoid the effects of changes
to libraries, presumably by refusing to use the new ones and keeping copies
of the old.  Okay, I'm willing to agree that these are real advantages.  What
hasn't been adequately explained to me is the belief that I/O is a less stable
programming language feature than, say, abstract data types or parallel
processing.  And where do we draw the line on this language design methodology?

The limiting case of the belief that the language should be defined by functions
is of course LISP, where it is possible to believe that all but about a
dozen functions are defined purely in LISP itself, including arithmetic
and all control structures besides COND.  I don't think that many adherents
of the manner in which I/O is defined in C would want to give up infix
arithmetic expressions for "add(x,y)", so I am interested in just what they
believe are the sufficiently stable set of constructs worthy of inclusion in
the "language" definition.  I feel that I/O operations on simple
character-stream devices and on files are, by definition, as stable and well
understood as operations on main-storage variables, since the only technical
semantic difference is the code that must be generated to do these operations.
This is why I propose using the same syntax.  Of course there will always be
people who want to hook up strange and complex equipment to computers,
such as automobile engines, Star Wars defense systems, marital aids and
Things Not Yet Invented That We Can Only Dimly Comprehend.
I never intended to imply that the control of such devices should in
any way be built into a compiler, interpreter, or even a standard object
library.  But, Mein Gott, aren't programming languages mature enough yet to
understand the concept of getting the nth record from a random-access file?
They can learn these concepts from their creators or they can pick them up
"in the streets", where each industrial implementor, seeing an opportunity
to use the reputation of the language to market its own products, will teach
the language how to connect itself to its own I/O system, usually of
questionable virtue, and will then begin selling this "improved" language to
all takers.  Is this what we want for our loved ones?


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