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

> Jim Blandy wrote:
>> Alex Shinn <foof at synthcode.com> writes
>> To be clear, are you advocating the use of two disjoint string types
>> in Scheme as in C?
>
> Among other things, I'm advocating distinguishing byte vectors and
> strings, as MzScheme does.  Is that what you mean?

  (although can't speak for Alex, it would appear)

- Presumably yes, but hierarchically tied; as would be implied by any
  encoding/protocol type layer being layered over a raw byte-stream
  type layer. (Thereby one's sequential content implies the other's, yet
  at any point in the sequence, one may interact with either distinctly;
  although would not imply a higher level layer sequence would not have
  it's encoding/protocol corrupted by an arbitrary modification of the
  sequence by a lower level layer, which in fact would likely occur,
  which seems to be your concern, but unavoidable unless implicitly
  allowed by the upper layer encoding/protocol itself.

  (Given the inherent incompatibility between arbitrary layers at the
   same level of hierarchy, or in different branches (i.e. different
   character sets), not to mention further ambiguities implied by what
   is not encoded in character sets alone; still wonder if the world
   would be better off attempting to define, and accepting a single
   canonical information encoding/protocol in the long run; as it seems
   generally understood that attempting to merely accommodate some
   relatively minor formatting and character encoding localization
   preferences, which can itself introduce some confusion, is clearly
   insufficient for the exchange of information across cultural/linguistic
   boundaries; if that's it's intended purpose, as opposed to enabling
   the application to appear more local culturally aware, but with no
   grander purpose than that.)


>> Layering and/or procedural ports is a nice approach, and one I would
>> like to see in a future SRFI, but is higher-level than I wanted to get
>> into with SRFI-56.  Given SRFI-56 you can implement layering (and
>> given layering you can implement SRFI-56) so it seems logical to start
>> with the lowest-level approach first.  People are then free to come up
>> with competing layering approaches.