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. ... Yes, therefore scheme need the fundamental ability to read/process/write data encoded in arbitrary encoded formats, which precludes it from assuming any single one. Therefore the lowest level canonical (null-encoded) form which scheme needs to support is pure binary I/O, storage, and manipulation; 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. -paul-