From: John Cowan <[email protected]> Subject: [r6rs-discuss] Proposed features for small Scheme, part 2 bis: I/O Date: Mon, 21 Sep 2009 21:22:54 -0400
> So I reluctantly came to the fourth alternative. A newly opened port > is ambiguous. If R5RS operations are done on it, it is marked textual > and remains so. If binary operations are done on it, it is marked binary > and remains so. This is a mess, but the need to remain compatible with > R5RS/IEEE and the desire avoid duplicating many of its routines led me > to see it as the least bad alternative. > > The binary operations provided are minimal: read-u8 (which is like > read-char), write-u8 (like write-char), and file-u8-position and > set-file-u8-position!. I support this. Actually R6RS I/O is a part I like in R6. It seems semantically clean to have distinct binary ports and text ports, and build the latter on top of former plus transcoder. Yet the API is abstract enough to allow different implementation strategy. However, I agree that the spec is rather large, for small Scheme. Dropping binary I/O can be a feasible option, *if it is complemented by binary I/O srfi (cf. withdrawn srfi-56)*. I'd argue that even for the educational purpose to describe algorithms, some sort of binary I/O is inevitable if you want to explain interaction with the external world. Without well-established API, however, the history shows people tended to use read-char and write-char (with char->integer and integer->char) to pretend binary I/O, which got broken beyond ASCII/ISO8859 world. So whether agreed binary I/O be in the core or srfi? It may depend how small we want the small Scheme to be. I prefer having read-u8, peek-u8 and write-u8 in the core. With them, the rest of binary I/O utility srfi can be defined portably, which benefits even minimalist Scheme. Without them, binary I/O srfi inevitably depends on implementation-dependent primitives. I'm not sure about port-u8-position and set-port-u8-position!. They are necessary for practical applications, but they seem to put more semantics on ports; without them, the ports are simply modelled as read-once/write-once stream of bytes or characters. With 'positions' suddenly we look at some persistent pool of data beyond them. I feel that we can omit them from the core and put them in system-interface srfi, with other system stuff like filesystem interface. But I don't have strong opinion here. On having a fresh port "ambiguous" and the first operation determines binary/character: It does seem tricky. I'm ok with that, but it may be problematic on a hypothetical system where you have to specify whether binary or text mode at opening the system resource. There may be also the case that created ports already have either binary/character orientation (e.g. string output ports may only be a character port). Because of this, it might be necessary to have a predicate to query whether binary-i/o or character-i/o is capable on a given port. --shiro _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
