[plt-scheme] Why do MzScheme ports not respect the locale's encoding by default?

So how about an srfi on canonical information, and in the process
rid the world of xml/etc. syntax altogether (can dream can't I).


> From: Paul Schlie <schlie at comcast.net>
>> From: Jim Blandy <jimb at redhat.com>
>> Just to keep things from getting foggy: the change I'm suggesting
>> falls in your first category ("enabling programming languages ..."),
>> not the latter ones ("alternative formatting convention ...").
> 
> I think I understand, and although believe that it's reasonable desire
> extended locale sensitive format library support functions; it would
> seem that they should more likely be controlled programmatically, (i.e.
> via explicit call parameters), not via local host's locale settings; as
> it would seem that when such flexibility is desired, it's just as likely
> that the locale scheme desired that of a remote platform; either on the other
> end of a wire, or file destined to be rendered elsewhere?
> 
> Ironically implying, that even locale sensitive formatting functions may
> not truly be required, as opposed to the definition of some canonical basis
> of the information itself; then implying a single universal format, from which
> other locale sensitive renderings may be derived; thereby implying
> the ideal need for very specific locale aware text/language rendering
> functions, but little need if any need for generalized locale aware formatting
> functions, as most processing would be done on the canonical,
> not localized representation of information.)
> 
> So rather than folks trying to figure out how to fiddle with various
> language sensitive encodings on each platform, wonder if it makes sense
> to spend the time and energy defining a standard canonical representation
> for basic stuff like date, time, location, numeric values, units, etc.
> thereby at least eliminating a bulk of the generic locale issues, leaving
> likely only the stuff which is too language/context sensitive to even be
> attempted to be handled in a generic way, as would require very specific
> processing, likely well beyond the scope of any specific language feature.
> 
> (possibly even beyond the scope of scheme's charter, but someone needs to)
> 
> 
> 
>