Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!linus!decvax!genrad!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.lang
Subject: Re: I/O operations in programming languages
Message-ID: <693@mit-eddie.UUCP>
Date: Sat, 3-Sep-83 20:15:43 EDT
Article-I.D.: mit-eddi.693
Posted: Sat Sep  3 20:15:43 1983
Date-Received: Sun, 4-Sep-83 14:01:47 EDT
References: <497@ritcv.UUCP>
Organization: MIT, Cambridge, MA
Lines: 43

Well, it's is now my turn to be a twit and join this stupid debate.
Someone made the point that leaving I/O out of the language definition
permits you to experiment with new I/O schemes.  This is just plain
wrong.  Just because a language has I/O routines doesn't mean that you
have to use them.  As long as the language has subroutines you can
implement new I/O architectures such as curses.

For example, I am a Multics system programmer, and as some of you may
know, Multics is a PL/I system.  PL/I has I/O in the language, but
Multics programming standards specifically say "do not use PL/I I/O, use
the standard Multics subroutines".  I also know a number of Unix system
programmers who never use the low-level stdio routines, they always use
the simpler Unix routines.

Here are my thoughts on the pros and cons of providing I/O in the
language:
1) portability: I don't think it matters.  Someone will have to write
some standard I/O routines, and it doesn't matter to me whether it is
the compiler writer or the person who ports the library.  In many cases
the I/O primitives might have to be written in assembler, so it would
probably be better if the compiler-backend-writer were implementing it, to
reduce the number of people who must deal with the machine language.

2) syntax: building I/O into the language has the feature that the I/O
routines have access to information about the data that is not generally
available at runtime.  Most language-I/O designs are generic, meaning
that they do the appropriate thing with all the language-defined data
types.  In PL/I I can just say "put list (foo)", and the value of the
variable foo will be printed in an appropriate form.  On the other hand,
with the move these days towards user-defined types and various forms of
packaging (Zetalisp flavors, Smalltalk classes, CLU clusters, Modula
modules, and Ada packages) this has become less attractive.  Another
nice thing that can be done in PL/I is "put data (LIST-OF-VARIABLES)";
this is like "put list (LIST-OF-VARIABLES)" except it also outputs the
variable names with each value, a very useful debugging tool (especially
if you leave out the LIST-OF-VARIABLES, in which case it dumps ALL the
variables).  Of course, this is not necessary if your system has other
good debugging utilities, but it is a good example of something that
cannot be done by a subroutine in any language I am familiar with.
-- 
			Barry Margolin
			ARPA: barmar@MIT-Multics
			UUCP: ..!genrad!mit-eddie!barmar