This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
While waiting for it to appear on srfi.schemers.org, you can get the latest version at http://synthcode.com/scheme/srfi-56.tar.bz2. I'll go into more detail about the rationale here. The only significant change is the addition of the binary/character port distinction. There are several reasons why a Scheme may wish to make this distinction: 1) Java and other non-systems languages may have limited support for intermixing binary and character operations on the same port. 2) Windows distinguishes between text and binary mode, and though this is easy to workaround by always using binary ports, some Schemes may wish to preserve the distinction. 3) Schemes may wish to disallow using binary operations on string-ports for simplicity and performance reasons. In the interest of greater portability, we first acknowledge that there may be a distinction, and provide the binary-port? and character-port? predicates, which are not necessarily mutually exclusive (they may both be tautologies). Testing alone does not help portability, other than to possibly display more informative error messages: (call-with-input-file my-database (lambda (p) (if (binary-port? p) (load-database p) (error "shucks, files aren't opened in binary mode by default")))) Indeed, providing this distinction without specifying how to open files in binary mode would hurt portability more than help, as people would simply use the native Scheme's method for opening binary files, and not bother to test the results of these predicates since they know how they opened the file anyway. So we provide a means of ensuring files are opened in binary (but not necessarily character) mode with six new procedures: * OPEN-BINARY-INPUT-FILE path * OPEN-BINARY-OUTPUT-FILE path * CALL-WITH-BINARY-INPUT-FILE path proc * CALL-WITH-BINARY-OUTPUT-FILE path proc * WITH-INPUT-FROM-BINARY-FILE path thunk * WITH-OUTPUT-TO-BINARY-FILE path thunk All of these return #t for BINARY-PORT? The corresponding R5RS procedures are guaranteed to return #t for CHARACTER-PORT? The reason for using new procedures instead of extending the existing procedures with optional arguments is to avoid clashing with already existing extensions to those procedures. In particular, a common extension is to make the port encoding an optional argument. In the Java model, which tries to limit mixing of binary and character I/O, "binary" itself is considered an encoding, but in the more general case the ability to perform binary I/O is orthogonal to the port's character encoding. Existing R5RS (character) I/O procedures are then defined to all be guaranteed when CHARACTER-PORT? returns #t, and the binary procedures defined in the rest of SRFI-56 are guaranteed when BINARY-PORT? returns #t. It is an error to use a character/binary operation on a port for which the corresponding predicate returns #f. -- Alex