A few random I/O proposals

["Guillermo J. Rozas" <jinx@martigny.ai.mit.edu>]

*   * 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.

I object strongly to the "return #f" solution.  It only leads to code
dying later in obscure ways because people forget to check.
An error/condition system can handle this reasonably well.

*   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.

There are other possibilities.
One of them would be to include the pair of procedures
make-string-output-port and string-output-port-content.

MIT Scheme has

  (with-output-to-string thunk)

and

  (with-output-to-truncated-string max thunk)

with-output-to-string returns a string.
with-output-to-truncated-string returns the cons of a boolean and a
string.  The boolean indicates whether the output was in fact
truncated (true if it was truncated, false if it finished).

It has string->input-port and with-input-from-port for input.