[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A few random I/O proposals
* * 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-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.