[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encodings.

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.



I think I agree, under the presumption that for a root binary data port,
there is a known correlation between data's external physical sequence and
its internal representation (in other words, agree that the internal raw
byte sequences accessible through ports, need not be literally stored
internally a physical sequence of contiguous bytes of storage, but do
suspect they would need to be minimally sequentially accessible as
arbitrarily sized sequence of bytes stored as a sized bob (binary object),
who's logical bit ordering is consistent with it's external physical storage
representation.

Where then these bobs (binary objects) which could then be operated on
as an aggregate entity consisting of arbitrary collection of enumerated
signed/unsigned integer fields who's values are extracted/inserted by
specifying their bit position boundaries within the bob's binary field;

That should be enough flexibility to get everyone in trouble.

-paul-

> From: bear <bear@xxxxxxxxx>
> 
>> On Fri, 13 Feb 2004, Paul Schlie wrote:
>>
>> Agreed.
>> 
>> 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.
> 
> 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.
> 
> Bear
>