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'm apologize if my tone was interpreted as being antagonistic. Although I may have abused the use of "canonical", my intent was to suggest that raw data I/O represents the fundamental basis required to support arbitrarily encoded data access; and in that respect, tried to suggest that null-encoding may be thought of as root canonical encoded form (where a null encoding transform does nothing, therefore lossless, fully preserving all the originally encoded data states in their native form); where then subsequent encoding transforms may be applied once within the scheme environment as required to extract more specific interpretation of the data as required, based on assumption or knowledge of its encoded representation through some means. However under no circumstances should scheme I/O be presumed to be based on any particular character encoding which may be different than the host platforms presumption; as otherwise the scheme's I/O interface would then need to presume the responsibility to transcode it's I/O, potentially destroying the integrity of data encoded in other forms (as you yourself implied). Although I don't think I have any axe to grind, I do have an interest in either preserving the use of character I/O as a useable basis for generalized data access, or requiring an alternative be formally defined, if the present character data types and I/O facilities prevent their use as such. (With respect to scheme identifiers being validly formed from an extremely broad character set, I simply just don't think it a good idea for the reasons I stated, but admittedly a lesser concern.) Thanks, -paul- > From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> > Date: Thu, 12 Feb 2004 19:35:16 -0800 > To: srfi-52@xxxxxxxxxxxxxxxxx > Subject: Re: Encodings. > Resent-From: srfi-52@xxxxxxxxxxxxxxxxx > Resent-Date: Fri, 13 Feb 2004 04:35:26 +0100 (NFT) > > Bradd W. Szonye wrote: >>> ... Storing data in non-canonical form is not "broken." Also, there's >>> more than one canonical form. ... Programs which disagree on the form >>> of the I/O will need to translate between the two. >>> >>> ... That wouldn't help unless they agree to write the *same* canonical >>> format. ... > > Paul Schlie wrote: >> Yes, therefore scheme need the fundamental ability to >> read/process/write data encoded in arbitrary encoded formats .... > > Whoah! That's doesn't follow! "More than one canonical form" is not the > same as "data encoded in arbitrary encoded formats," and therefore your > "therefore" is incorrect. > >> Therefore the lowest level canonical (null-encoded) form which scheme >> needs to support is pure binary I/O, storage, and manipulation; > > While I agree with your conclusion, this "therefore" is also invalid. > >> upon which multiple data encoding scheme's may be defined, and invoked >> as required based on local environment, and/or application specific >> data encoding and processing requirements (which incidentally is not >> restricted to text, as data may often be represented various encoded >> forms; examples of which include dozens of various audio, video, >> image, telemetry, modulation, etc. data streams), none of which should >> require that scheme's implementation be non-standardly or >> proprietarily extended for the mere privilege of being able to access, >> manipulate, and subsequently store data in whatever encoded form may >> be available to it, or as may be required. > > Er, what? It sounds like you have some axe to grind, and you're using > any excuse to pull out the grinder. > -- > Bradd W. Szonye > http://www.szonye.com/bradd >