A few random I/O proposals

[david carlton <carlton@husc.harvard.edu>]

I think that the I/O section needs to be straightened out some.  Here
are things that I think are bad about it:

* It is impossible to open a file while allowing for the possibility
that it might not be openable.  The section on open-input-file says
that "If the file cannot be opened, an error is signalled"; this may
be okay for some circumstances, but there are times when you want
something better than this.  Two solutions that have been proposed are
to have some other value be returned in this circumstance, #f being
the obvious choice; or to allow the user some way to signal errors.
The former has the advantage that it allows for somewhat more concise
code and that it does not treat the non-existence of a file as an
exceptional case but rather as something that you should expect to
happen occasionally.  (Admittedly, you may not consider either of
those to be advantages.)  The latter has the advantage that it is a
compatible change, that the solution is applicable to other
circumstances, and that it makes it possible for this situation to be
handled analogously by procedures that both try to open files and
return useful values, such as call-with-input-file.

* There are no guarantees about when output will in fact appear.  This
makes it impossible to portably prompt the user.  Actually, this makes
it impossible to portably communicate with the user; in practice, the
only time that I've had a problem with this is with Yale T which,
quite legally, does not flush output unless you explicitly tell it to
or (I think?) unless a newline is outputted, making it impossible to
write portable code which prompts a user and works under T's scheme
mode.  I don't think that there is any way to handle this prettily,
but perhaps words could be inserted saying that implementations are
encouraged not to buffer output that is being sent to interactive
ports, if possible.

* There should be some sort of way to get the printed representation
of an arbitrary object in string form, and to read the printed
representation of an arbitrary object from a string.  The report
currently has some sort of nonsense about read/write providing an
elegant and powerful i/o facility, but it isn't nearly as powerful as
I would like, and I don't think it's all that elegant, either.  The
obvious way to handle this is to add some sort of string ports to the
language.  Adding a procedure open-input-string which returns a port
which reads successive characters from the string would solve the
input problem fairly nicely, but unfortunately a procedure
open-output-string wouldn't make nearly as much sense, since strings'
lengths are immutable.  You could still do that by having
close-output-port return the value of the string that is constructed
or by passing open-output-string a cons cell and having the
constructed string placed in the car of the cons cell; both of those
solutions are fairly ugly.  Another possibility is to add
write-to-string and display-to-string functions which return a string
with a printed representation of their argument.

* Load should be better specified and made nonessential (or removed
entirely, but that might be overkill); there has of course already
been discussion on this point, so I shan't belabor the point here.

david carlton
carlton@husc.harvard.edu

       World War Three can be averted by adherence to a strictly
       enforced dress code!