John Cowan wrote: > Alternatively, textual and binary ports could be completely > separate with no way to derive or convert one to the other. This, > however, means that many of the R5RS procedures must be duplicated: to > input-port? we add binary-input-port?, and to open-file-for-input we add > open-file-for-binary-input (which dynamically binds current-binary-input), > for example. This duplication seems inappropriate in a small Scheme. > It would not aggrieve me at all if WITH-foo-FILE and CALL-WITH-foo-FILE were not duplicated for binary input in the Standard. Useful as string ports are, I personally have never missed WITH-OUTPUT-TO-STRING, for example. Or CALL-WITH-OUTPUT-SOCKET. The only remaining duplicates, then, are constructors and type predicates.
We have one object, the binary port. It admits one set of procedures (read-u8 et al) that accept or return one type of value (small exact integers). We then have another object, the textual port, that admits another set of procedures (read-char et al) and returns another type of value (chars and char aggregates). Why should these objects not have disjoint types? It is possible to construct each from a pathname into the filesystem, in certain circumstances. That is all that they share. Their other constructors (string -> text port, serial I/O device -> binary port, binary port + transcoder -> text port) would not admit of any duplication. Ben _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
