On 23 Sep 2009, at 2:43 am, Shiro Kawai wrote: > 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.
It might be "more schemeish" to have a clone-port operation instead. Get the port to be where you want it, and clone it, then you can go back and read from the clone to return to that position. Makes the invisible inner state of the port less prominent, and eases the implementation of ports that are actually generated algorithmically like PRNGs, and prevents the "start of the file" being a specially privileged thing. However, this should then be partenered with a "discard" operation that discards N bytes from a port, or else you suffer from the other reason to seek on a file descriptor - to skip to a specific position in the file. > 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. The actual open can be done lazily, though > 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. Yes, that would be a good idea. A port with a #f codec explicitly set on it would be incapable of character I/O, for example, and would highlight mistakes if people opening a file they know won't have any text in set it that way. > > --shiro > ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
