Per Bothner <xxxxxx@bothner.com> writes:

> The benefit is for the implementors: If you specify ports that can
> arbitrarily mix text and binary then implementors can no longer
> use common abstractions and existing libraries.

Well, if you don't allow this, you also prevent common abstractions.
As to the use of "existing librariers," you can use the reference
implementation---that's why I wrote it.  It seems a bad idea to
restrict a library because a restriction might exist in some other
library you might choose to use to implement it, or because it's
otherwise hard to implement.  (The same could be said for many other
aspects of Scheme.)  By extension, you'll only ever get the least
common denominator, and it'll keep getting smaller.

> An implementor can no longer use the existing APIs for "character
> ports", but mus instead use "binary ports" and do their own
> character->binary mapping.  True, this isn't very difficult given
> that SRFI 68 only directly supports UTF-8,

I'm not sure what you mean by "directly," but SRFI 68 specifies
transcoders for Latin 1, UTF-16, and UTF-32.

> but there is still a type mismatch problem between Scheme ports
> (implemented using native binary ports) and native character ports:
> E.g. I cannot pass a Scheme port to a Java method expecting a
> Reader/Writer or vice versa.

While it's not an approach I'd advocate, I'm unclear on what exactly
would make that impossible.  Last I looked (which, admittedly, was a
long time ago), Java text "ports" were built on top of binary "ports"
in Java.  This should allow you to use the underlying Java objects for
modelling ports.

> Implementing a translator may be difficult.  For example, while Java
> has had general support for text ports with multiple encoding, it's
> only relatively recently (JDK 1.4) the translation machinery has
> been directly available.  I think it is possibly to implemented
> translated streams without direct access to the translation service,
> but it requires a high-overhead pipeline.

I'm unclear on what your point is---if you want to know how easy or
hard it is to write custom transcoders, look in the reference
implementation on how the UTF transcoders are done.  Certainly, the
pipeline doesn't have especially high overhead.  (For any reasonable
notion of high I can imagine.)

> The default encoding of a character port *must* be the
> "native" encoding of the user's locale.

No, it must not be, especially as the idea of a "native encoding"
associated with the locale is shadowy at best.  For example, your OS
might have a notion of locale, but simply sport separate I/O
procedures for different text encodings.  That's the case on Windows,
for example.

> I don't see how anything else can even be seriously considered: a
> beginning Scheme programmer should be able to write a simple program
> that reads or writes a file without having to set up translators, or
> specify an encoding.  SRFI 68 appears to contradict this
> requirement.

I don't think so---at least that wasn't my intention.  Where do you
think does SRFI 68 contradict you?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla