A few random I/O proposals

[kend@data.rain.com (Ken Dickey)]

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

Note that I also proposed (FILE-EXISTS? <whatever-filespec-rnrs-accepts>)
so that in the trivial case the problem could be avoided.  I believe
that the handler proposal, if accepted, could be worded to support the
facility you desire.

> * 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 problem with this is that (1) you typically want the abstract
object {i.e. recreate a record or instance rather than letrec'ed
lambdas} and (2) you need to be able to print nested and circular
structures.  One can certainly do this locally and as part of the
programming environment, but I can't see adding this to the language.
Environmental features are by definition not part of rnrs.

Output to strings can be dome using (format #f ...) {in the Scheme
Repository}.  String ports make it much easier to do, however.  I
would like standard string ports!

-Ken