1. Overall, I think the treatment of eof objects is fine, but there is one deficiency in the current draft. Generally, Scheme tries to provide type discriminators, constructors, accessors, and mutators for its types; however, there is no constructor for the eof object. Yet in fact an eof object can be constructed in standard portable R7RS Scheme, using the idiom which I think many Schemers are familiar with:

(let* ((p (open-input-string ""))
       (x (read p)))
  (close-port p)
  x)

I'd therefore suggest adding a procedure named make-eof-object or some such, and defined to return one of the set of eof objects for the implementation.

This isn't just an attempt to create a vain orthogonality; there are good reasons why arbitrary code might wish to return an eof object. For example, a DBMS interface might have a routine that returns one row, as a list or a vector, at a time; after the last, it is perfectly reasonable to return an eof object.

An argument against providing this is that the constructor may be trivially written, as shown above. A similar argument could be applied to zero?, newline, quotient, remainder, and modulo, among others. R7RS is not afraid to provide easy-to-implement procedures in the name of simplicity, orthogonality, or historical compatibility. I think the lack of an eof constructor is worth remedying.

2. I'm not sure I understand the difference between `input port' and `port capable of doing input operations'. The draft offers input-port? and output-port? that are true if the argument is an input (or output port). Yet close-input-port and close-output-port are clearly defined to shut down the input or output side of a port, leaving the other side still functioning, and explicitly work on things that are not input (or output) ports. This is all good language design, and I'm fine with the functionality described here. However, if an implementation offers some kind of input/output port, I'd ask `is this an input port?' and `is this an output port?' I think the draft would say No (which I would not agree with, but appears to be the intention in the {input,output}-port? entry), but I'm not sure. Could I therefore ask that the entry for {input,output}-port? include a sentence or two that is comparable to that for close-{input,output}-port saying what happens in such cases.

  > (define p (open-input/output-file "/dev/tty")) ; implementation-provided port type.
  > (input-port? p)
  ???
  > (output-port? p)
  ???
  > (input/output-port? p)                         ; implementation-provided procedure.
  #t

I'd like the ???s to be replaced with #t, but even if the result is required to be #f at least people will know what these type discriminators do.

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