Peter Bex scripsit: > Codecs sound too much like special-casing to me. If custom ports are > supported in Thing One,
I looked at the R6RS specification of custom ports and ran away screaming. Maybe something simpler should be provided, though traditionally the topic of streams is handled by something other than a port in Scheme-based education, typically a list whose cdr is a promise. Still, I'll take another look, and maybe hack out something. > couldn't "codecs" be handled simply by a procedure accepting a port > and returning a new port which applies the codec to the original port? Pre-final drafts of R6RS did have this notion of stacking transformers on top of ports, but as I and others pointed out, a octet-port -> char-port transformer is very different from a char-port->char-port transformer. So transformers don't really stack. In the final R6RS, calling transcode-port on a binary port creates a new character port all right, but it leaves the underlying port in a publicly closed but secretly open state. This is done because transcoding is best done in bufferloads, and the state of the binary port will be undefined after character operations have been done on the character port. So transcode-port is really a side-effectful procedure, and I prefer to represent it as such. -- Dream projects long deferred John Cowan <[email protected]> usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
