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

Re: Octet vs Char (Re: strings draft)

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 are here. Eventually, the entire history will be moved there, including any new messages.



Which is the very reason that specifying a character encoding for scheme's
character-set breaks most existing implementations', and programs hosted
on those implementations, assumption of i/o port and string encoding
neutrality.

As because the standard "goes of it's way *not* to assume a particular
character encoding and repertoire", it enables implementations to adopt
the host's native character encoding as it's own; thereby forming an
equivalency between characters and raw-native-byte data, thereby enabling
the use of scheme in a wide variety of applications which require raw byte
i/o, and data butters (using scheme's native i/o ports and strings to do
so).

This alone would seem to be a good reason to continue not specifying
scheme's character encoding, enabling it to remain equivalent to the host's
native-byte data encoding. Where then, new standard scheme procedures can be
defined to encode and manipulate encoded data stored within native-byte
scheme strings as required for whatever specific purpose desired; and/or
alternatively, distinct "world aware" character and string types, with
whatever magical properties they may require could be defined, independently
of the existing encoding-agnostic byte-oriented i/o ports and strings.

-paul-

bear <bear@xxxxxxxxx> wrote:
> Hear, Hear.  The standard goes out of its way to *not* assume
> a particular character encoding and repertoire; it follows that
> code relying on a particular character encoding in order to do
> binary I/O is nonportable.