This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.
> Paul Schlie wrote: >> But feel compelled to observe that once an object's internal representation >> is formatted/encoded to/from whatever external representations form is >> desired/required, it is then essentially in binary form; therefore binary >> I/O actually represents the root common port format for of all I/O; where >> more abstract ports may be thought of as merely munging on the data prior to >> sending (or after receiving) it trough a binary port; which although it may >> seem like a subtlety, if scheme were to view ports in this hierarchical way, >> it could form the basis of a very flexible data transformation and I/O >> architecture. bear wrote: > Central idea: Right. If the binary port is primitive, then the > various kinds of character ports can be provided as libraries. > > I take issue with several of your "therefores" though; while I agree > with your conclusions, I don't think that the internal representation > of any kind of data is, or should be presumed to be, at all similar to > that which passes through a binary port. That's roughly my feeling too. I agree with some of his basic conclusions, but I disagree with many of his reasons for them. For example, I think it's splitting hairs to call it "binary I/O" when you're reading or writing in the machine's native text format. In some cases, it's downright misleading; for example, the native text format on a VMS system is record-based and cannot be represented as a binary stream. Because of that, I think it's a mistake to claim that binary I/O is more primitive than text I/O. On some systems, the two are entirely orthogonal. For UNIX-like systems, you can implement text on top of binary, but it's not generally possible. Something to keep in mind when specifying port & string standards. -- Bradd W. Szonye http://www.szonye.com/bradd