> 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