Re: [Scheme-reports] I/O redux

[John Cowan <cowan@x>]

Vincent Manis scripsit:

> 1. [Old] Re my proposal for STANDARD-{INPUT,OUTPUT,ERROR}-PORT. John
> Cowan (I think) felt that these were useless.

You've convinced me enough to file a ticket for this.

> Also, are these ports always defined? Is it possible that
> CURRENT-INPUT-PORT might not be set at all, or might have value #f, in
> some cases? If I'm not mistaken, a Windows executable has no standard
> input or output.

They're always defined but might be closed.

> I would also put in a weak suggestion for CONSOLE-INPUT-PORT and
> CONSOLE-OUTPUT-PORT,

I think that's piling Pelion on Ossa.

> 2. [OLD] The fact that IEEE Scheme is required to be a subset of WG1
> is sufficient reason to include CHAR-READY? and U8-READY?.

I don't care for these myself, so I can't judge the validity of your
suggestions.

> [I assume that few if any implementations would use non-blocking I/O
> just so they can support CHAR-READY? correctly.]

No, but they might use non-blocking I/O to get the right results with
(implementation-dependent) threads.

> 3. [Old] I had suggested adding a remark that some implementations
> support other kinds of sources and sinks beside files (and
> devices). John remarked that this is addressed in the first paragraph
> of §6.7. That says that other kinds of ports besides binary and
> character might be provided, which is a different point. My remark was
> aimed at conveying that an implementation might provide other kinds of
> binary/character ports that the procedures in §§6.7.2 and 6.7.3 will
> handle.

Good point.  Added text.

> 4. [Old] I had expressed confusion about the notion that binary
> ports inherently support character operations. This morning I had
> an epiphany on this subject. To me, a `binary port' is a port that
> is used to read or write successive octets, while a `character
> port' contains additional encoding support, even if it's just
> end-of-line translation. Thus in C-derived I/O systems one might do a
> fopen(filnam, "r") for character reading, and fopen(filnam, "rb") for
> binary reading.
>
> This is NOT how these terms are used in the Report! A binary port is
> one whose backing store (on disk or elsewhere) contains octets, while
> a character port (e.g., a string port) has a backing store containing
> Scheme characters. The term `binary' doesn't refer to reading or
> writing in binary mode, but to the type of backing store the port
> uses. This is implied, but not stated, by the current wording, leaving
> people like me relatively free to misunderstand the point.

Added clarifying text.

> 5. [New] §6.7.1, bottom of col 2, p. 45. WITH-INPUT-FROM-FILE and
> WITH-OUTPUT-TO-FILE are defined, but should not WITH-ERROR-TO-FILE
> also be added?

My feeling is that it's not useful enough: redirection of standard
error should typically be done at program invocation time.  A program
that wants to rebind standard error to syslog or the like can do so by
passing a suitable port argument to CURRENT-ERROR.

> 6. [New] Most implementations provide a procedure named something like
> READ-LINE that reads the next line from an input port. Processing a
> file by lines is an extremely common paradigm, and should therefore be
> supported.

This should have been voted on but was overlooked.  A ticket has been
filed.

> 7. [New] What happens if both READ-CHAR and READ-U8 are used on the
> same port? I can envision several possible answers.

It depends on the buffering setting, but this is badly explained and,
I now think, badly designed.  I'm going to try again with binary vs.
character ports with a new proposal.

> 8. [New] §6.7.4: LOAD/INCLUDE. Some implementations use LOAD's
> argument to name a file, others do some kind of path search, or do
> some other transformation on the name. Gambit, for example, uses a
> prefix of ~~/ to signify looking in the Gambit directory. I suggest
> replacing `_filename_ should be a string naming an existing file
> containing Scheme source code' with `An implementation-dependent
> operation is used to transform _filename_ into the name of an existing
> file containing Scheme source code'.

Done.  All of the above have been pushed.

-- 
Real FORTRAN programmers can program FORTRAN    John Cowan
in any language.  --Ed Post                     cowan@x

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports