Re: I/O proposal

[Kent Dybvig <dyb%unc.csnet@csnet-relay.arpa>]

I think the overall proposal is quite nice.  I do have a couple
of remarks and minor suggestions, though.

1.  I would prefer a settable *eof* variable.  It is useful sometimes
    to specify the value returned on eof.  I also think "eof?" is
    unnecessarily complex (giving implementors free reign is not
    the most important issue here).  Besides, if you ask ten people
    what they think the function "eof?" does, chances are all ten
    will say, "it takes a file as input and returns true iff the
    file is at eof."  No big deal here, though.

2.  I do not think the programmer should be encouraged to change
    the default input/output streams.  This leads to confusing or
    even dangerous behavior when an error or interrupt occurs.
    The exception handler normally wants to operate in the same
    environment as the interrupted routine, in order that the
    user can query the environment (perform stack walkbacks, check
    values of variables, etc.).  Imagine if the handler prints
    a message and queries the user but receives its input from a
    disk file because the default input file has been rebound,
    e.g. "Really delete *.*? (y/n): ".  For this reason, I think
    the names should be "default-input-stream" and
    "default-output-stream", rather than "current-...".  Of course,
    "with-input-from-file" and "with-output-to-file" should not be
    supported.

    I have had experience with this very issue, and troublesome
    problems really do occur.  I do not want to write every piece of
    code to guard against someone changing the default input/output
    files on me.  I guess we could provide "console-input-stream" and
    "console-output-stream" functions, but this seems to complicate
    things unnecessarily.

    I think it's a good practice anyway to use explicit stream
    arguments.

    By the way, why are these functions instead of variables?
    Isn't this (only perhaps) helping implementrs at the expense
    of added complexity?

3.  Why have "call-with-input-file" and "call-with-output-file"
    rather than an expression-oriented syntax?  I think that the
    extra level of nesting will be nasty and people will likely
    just define syntactic extensions to get rid of it anyway.
    (reference my earlier note) I propose:

    (with-input-file (<id> <string>) form ...)
 	and
    (with-output-file (<id> <string>) form ...)

    with the same semantics.  Each set can easily be defined in
    terms of the other, but if one is standard it should be the
    simplest one to use.

4.  I prefer the name "write-char" to "display-char".  I take it
    the rationale is that "write-char" might imply that it may
    be read back in by the function read as a character.  I don't
    think this is really going to cause confusion; after all, it
    may be read back in by read-char, so read-char/write-char is
    parallel to to read/write.

..Kent