Vincent Manis scripsit:

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

Done.

> Some implementations may provide additional procedures that create
> ports representing other sources or sinks of data.'

The first paragraph of the section essentially says this.

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

Done.

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

That's the trick we (and SRFI 91 and Gambit Scheme) use here: binary
ports support character operations, but not necessarily vice versa.
The R6RS approach, where character ports are layered on binary ports,
requires the hack that when you have done such a layering, the binary
port is still open but effectively unusable.  Identifying the binary and
character ports makes more sense to me, and evidently the WG agreed.

However, there are still problems around buffering: the current solution
is usable but grossly inelegant.  I am still trying to think up a better
answer for the next ballot.

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

I don't really see any need for these.  (Note that parameters in R7RS
are not settable, though they are bindable.)

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

You're right on both counts.

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

It already says "If a file with the given name already exists, the
effect is unspecified."

> 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?

SRFI 6 is silent, so we are too, so as not to break existing
implementations.

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

I don't like them either, but CHAR-READY? is IEEE, so it must be kept.

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

There is a ticket about naming bytes/octets already.  However, the
current WG2 proposal does provide S8, U16, S16 etc. etc.

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

Ticket already filed.

--
My corporate data's a mess!                     John Cowan
It's all semi-structured, no less.              http://www.ccil.org/~cowan
    But I'll be carefree                        cowan@ccil.org
    Using XSLT
On an XML DBMS.

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