Herewith are my comments on §6.7, Input/Output.

1. [Trivial point] p. 45, col 1, 4th para. `Ports can be used to access objects called _files_...'. I mildly object [sic] to the language here. First, files aren't objects in the sense of the definition on p.3 (`Types are associated with values (also called objects) rather than with variables.') Perhaps files are entities or things, but not Scheme objects. Second, most operating systems allow programs to access devices as well, such as /dev/food-processor and COM2. I suggest `Ports can be used to access files and devices...Some implementations may provide additional procedures that create ports representing other sources or sinks of data.'

2. p.45 col 2. I assume that input and output ports are not disjoint, because an implementation might provide ways of creating a bidirectional port, even though WG1 (quite properly) provides no mechanism for doing so. Suggest adding a sentence that says `whether the input and output port types are disjoint is implementation-dependent.'

3. pp. 45-6. My eyes must have refused to see the specification of the mechanisms for opening character ports. Or perhaps that spec is written in invisible ink. Does PDF support writing with lemon juice?

I'm actually somewhat confused about binary and character ports in the Report. The statement `Every binary port is automatically a character port' seems backward to me. I would have thought that binary ports were lower-level than character ones, which presumably add some kind of transcoding (defined in WG2). Perhaps this could be rethought? If not, I'd say a few more sentences of explanation are needed.

4. p. 45. Add STANDARD-INPUT-PORT, STANDARD-OUTPUT-PORT, and STANDARD-ERROR-PORT. These could either be variables or parameters that are never mutated. The CURRENT-*-PORT parameters are initialized to the corresponding STANDARD-*-PORT values. Add mention that these might not exist on some implementations (e.g., on a Windows program linked as a Windows executable). They can be #f in such a case.

In I/O libraries I've written, I've had reasons why I didn't want to close the standard files. Is closing these valid in WG1? If so, can they be reopened? (I'm guessing the answer are yes and no respectively, but just asking).

5. p. 46. For OPEN-OUTPUT-FILE. Add `The effect of opening an output file that already exists is implementation-dependent.' (This hides the choice between destroying and re-creating the file and truncating it to zero length.)

6. p. 46. For GET-OUTPUT-STRING. It's explicitly allowed to call this twice, perhaps or perhaps not after adding additional data to the port? Can I call it on a closed string port? (Aesthetic note: the naming of procedures is consistent with the string ports SRFI, but if I could rename them, I would have chosen OPEN-INPUT-STRING-PORT and OPEN-OUTPUT-STRING-PORT. I'm not suggesting they be changed, just grumbling about the dead hand of history.)

7. p. 46, CHAR-READY? I actually believed all the propaganda I've read over the years about how this is essentially unimplementable on modern systems. `Oh, who will rid me of this meddlesome procedure?' (Funny, that technique worked for Henry II). I think a note should appear in the Report about how to implement this reliably without ever blocking trying to read a character. Given the existence of CHAR-READY?, U8-READY? is a logical consequence, but I'd prefer both to go away.

8. p. 47. I'm not in love with U8 as a name anywhere, especially given that WG1 doesn't offer U16, U32, etc., and, further, binary files are read by bytes. I would prefer the names READ-OCTET, PEEK-OCTET, WRITE-OCTET, and (ugh!) OCTET-READY?. A lesser but acceptable naming scheme would be to replace `OCTET' in thse names by `BYTE'.

9. p. 47. Output primitives. Given that there's mention of buffering in the Report, some mechanism for flushing is needed. Suggestion.

  (FORCE-OUTPUT)
  (FORCE-OUTPUT port)

  Attempts to ensure that any buffered data for port (default, value of (CURRENT-OUTPUT-PORT)) is written. On particular implementations, although no buffered data might remain, writing may still be in progress to the device.

  The waffle language is intended to indicate that the equivalent of fflush is done, rather than fsync.

10. §6.7.4 isn't really about Input and Output. I suggest renaming §6.7 as `Input, output, and system operations'.

-- vincent

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