This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
Per Bothner <per@xxxxxxxxxxx> 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