Alaric Snell-Pym scripsit: > 1) An implementation that has single-byte characters, and wants to > provide text and binary I/O either because it's a requirement of the > user base, or just because it ought to be trivial to do so in such > an environment, for which a unified port object with both read-u8 and > read-char etc. are fine, and u8-position = text-position.
My proposal handles this one fine, if it's made implementation-specific what to do when trying to do mixed I/O from a port. (There is no text-position, but it's trivial to have in this case.) > 2) An educational/proof-of-concept implementation that needs enough I/ > O to implement a repl, perhaps some library system internals, and some > toy examples, for which R5RS text ports would do just fine. My proposal obviously handles this: don't implement the %binary feature. > 3) A Unicode implementation that supports a few simple encodings - [...] > in which case, a unified binary+text port is OK, with a small amount > of state to select a codec and an optional endianness, and read-char > implemented as reading bytes until it's got a whole codepoint to return. Except that that's a terrible strategy more suited to the proof-of-concept implementation. I quickly found that out in Java, which allows you to push buffering on top of both an InputStream (binary port) and a Reader (textual port); if you don't do both, performance suffers. So the canonical thing is to open some type of InputStream, construct a BufferedInputStream from it, then construct a Reader from that specifying a suitable encoding, and then construct a BufferedReader from that. That's what I would hope a Scheme of this type would do internally. > 4) A "full" implementation that can read text in arbitrarily complex > encodings with arbitrary complex state. [details of nightmare scenario snipped] > The above musings suggest to me that it'd be a shame to disallow > simple mingling of text and binary as per cases 1,2,3 just because of > case 4, but I am leary of marking some cases as 'uncommon, and people > in this case must suffer for the common good' too hastily; while case > 4 suggests that what we really want to support that kind of thing is a > layered-ports system (where the fixed-size-buffers thing would be a > custom port layer function from binary port to binary port, which can > then have a function from binary port to text port applied). In such a > layered port system, the semantics of access to the underlying port > depends on the layer function, which should document it. I basically agree, except that case 2 is really no case at all, and I think you have misinterpreted case 3. > So, after this long ramble, what can I conclude? > > I think it's practical to have a system that lets you mingle binary > and text operations *as long as you're using a supported encoding*. Which amounts to saying, it is implementation-depedent what happens. Which is fine with me. > or use a blob system with blob->string functionality, and create blobs > by stitching your fixed-size frames' contents together. Which is one of the things the All-Singing, All-Dancing Blob SRFI will permit. -- On the Semantic Web, it's too hard to prove John Cowan [email protected] you're not a dog. --Bill de hOra http://www.ccil.org/~cowan _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
