Re: I/O proposal

[Will Clinger <willc%indiana.csnet@csnet-relay.arpa>]

We thank everyone for their comments on the I/O proposal.  Here
are our responses.

>Also, I think that you should have both "STREAM?" and its components
>"INPUT-STREAM?" and "OUTPUT-STREAM?", because it makes more
>information available without really constraining the implementation
>in any fundamental way.  Clearly bidirectional streams can satisfy
>both predicates.

Agreed.  Any dissent?

----------------------------------------------------------------

>The only objection I have is the
>use of the word STREAM for the IO stuff.  My problem is that we used that
>word all through chapter 3 of our book to mean the functional programming
>idea of (potentially) infinite sequence.  It will be very painful to change
>that.  I propose that the word be changed to one of CHANNEL, PIPE, PORT, TUBE,
>or any other appropriate euphemism.  I believe that my use of the word STREAM
>is consistent with that of other authors on functional programming.

>-- I oppose the term "stream" and thus the names STREAM?, CURRENT-INPUT-
>STREAM, etc., for the reasons Gerry gave.  We use "port".

Good point, so the names will change as follows:

	old name			new name

	stream?				input-port?
					output-port?
	current-input-stream		current-input-port
	current-output-stream		current-output-port
	close-input-stream		close-input-port
	close-output-stream		close-output-port

----------------------------------------------------------------

>-- What happened to the names PRIN1 and PRINC?  Are your WRITE and DISPLAY
>meant to be equivalent, respectively, to PRIN1 and PRINC?  As I understand
>page 382 of the Common LISP (CL) book, your WRITE is not incompatible with
>CL's.  Likewise, CL doesn't seem to have a DISPLAY.  However, I am bothered
>by my intuition that DISPLAY should be a terminal-oriented operation.
>
>   Bottom line: I vote to go with WRITE and DISPLAY, but the names PRIN1
>and PRINC should be reserved as well (as optional aliases).  The PRINT
>operation should also be optional, with the CL-compatible meaning we agreed
>on at the workshop.

Yes, WRITE and DISPLAY correspond to Common Lisp's PRIN1 and
PRINC.  For that matter they correspond to T's PRINT and DISPLAY,
and to Scheme-84's DISPLAY and PRINT.  Common Lisp's WRITE takes
a stream as a keyword argument whereas Scheme's WRITE takes a
port as an optional argument.  If that incompatibility doesn't
bother you then it certainly doesn't bother us.

PRINC and PRINT are used in the Abelson and Sussman book, but we
don't think they deserve or need formal status.

----------------------------------------------------------------

>2. "A different set of procedures will be needed to create streams from
>and to strings, and the closing procedures should still work on them.
>It seems that closing a string output stream should yield a string, but
>it isn't clear what should be returned when a file output stream is
>closed."
>
>I don't understand this at all. The phrase "create streams from and to
>strings" is rather difficult to parse, which doesn't help.

Scheme doesn't have anything comparable to Common Lisp's
READ-FROM-STRING, WRITE-TO-STRING, WITH-INPUT-FROM-STRING, and
WITH-OUTPUT-TO-STRING.  When we get around to adding those
capabilities, we will want to package the strings up to look like
ordinary I/O ports that can be passed as the optional argument to
READ and WRITE.  It appears that the designers of Common Lisp
didn't quite figure out how they wanted to do it either.

----------------------------------------------------------------

>3. Are with-input-from-file and with-output-from-file the only way to
>change the value of (current-input-stream) and (current-output-stream) ?
>If so, shouldn't they be essential ?

We agree that this is somewhat inconsistent, but there are
difficulties involved with specifying the correct semantics for
WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE, as well as difficulties
involved with implementing them correctly, so for the time being...

WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are the only ways
defined in the proposal to change the default input or output
ports.  Implementations may feel that the default ports should
always be the keyboard and screen, or they may prefer alternative
ways to change the default ports.  The main reason for making
WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE optional rather than
essential, however, is that we are not certain of the best way
for them to interact with escape procedures, and it seems a good
idea to keep uncertainties like that out of the essential
language until we understand them better.

----------------------------------------------------------------

>-- DISPLAY-CHAR seems to be a redundant, restricted form of DISPLAY. Since
>DISPLAY is essential, DISPLAY-CHAR should be dropped.

At the workshop it was emphasized that characters may overlap
with numbers, strings, or what have you.  If characters are just
numbers, then (DISPLAY #\SPACE) will print something like "32"
whereas (WRITE-CHAR #\SPACE) will print " " (without the double
quotes, of course).

>I wonder why you chose the name "DISPLAY-CHAR" rather than
>"WRITE-CHAR"?  I prefer "WRITE-CHAR" because it has no connotations of
>display terminals, or of being viewed by a human; it says, simply,
>that the character was written down somewhere.

WRITE-CHAR it is.

----------------------------------------------------------------

>I don't see any reason for LOAD and CURRENT-INPUT-STREAM to interact,
>and I think it is much better for them not to.  If they don't interact
>you have a much better invariants on each, e.g.: doing LOAD on a file is
>the same as doing LOAD on a file consisting of the string "(begin "
>appended to the file appended to the string ")".

We agree entirely, and are flushing the sentence in question.

----------------------------------------------------------------

>-- The name LISTEN? also is slightly unintuitive to me; how about INPUT?,
>or MORE-INPUT?, or something with "peek" in it.

LISTEN? is named after the LISTEN predicate in Common Lisp.
"Peek" calls to mind MacLisp's TYIPEEK, which is unrelated.
We're willing to change the name, and the following are the leading
candidates:
		CHAR-READY?
		INPUT-READY?

Please send your votes to brooks@indiana before 25 March.

----------------------------------------------------------------

>-- Does READ-CHAR wait for interactive input or return an eof token if
>nothing has been buffered up from the keyboard (or comm device, etc)?

It waits.

----------------------------------------------------------------

>-- With my Pascal (and English) background, I can't help but think of
>features named with "with", like WITH-INPUT-FROM-FILE, as syntax, not
>procedures.  [Did you notice how I began the previous sentence?]  I would
>prefer a special form: (WITH-INPUT-FROM-FILE <file-name> exp ...).  This is
>more consistent with CL's macro WITH-INPUT-FROM-STRING.  The same goes for
>WITH-OUTPUT-FROM-FILE.

We prefer procedures to special forms, and we followed MIT's
names here.  It is hard to come up with good names for these
procedures.



    Thanks again to all who are commenting on the proposals.

				Gary Brooks and Will Clinger