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.
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