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.
Michael Sperber wrote: > 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. The abstraction [or may "functionality"?] of "writing a character or string to a binary file" is meaningless. The functionality of "writing a character/string in a specific encoding" does make sense. I agree the functionality of writing a binary file that can contain embedded UTF-8 strings is meaningful and useful. However, this functionality is different from a character-stream API. > As to the use of "existing librariers," you can use the reference > implementation---that's why I wrote it. > ... > I'm not sure what you mean by "directly," but SRFI 68 specifies > transcoders for Latin 1, UTF-16, and UTF-32. Are you serious? These are all trivial, and few people (no-one?) uses UTF-16 or UTF-32 for file storage/transmission. How do you plan to support all the other Latin-X character sets, JIS, GB 2312-80, and ISO 2022? > 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 I don't want to write transcoders. Other people have already written then, and it's a lot of work, and a lot of large tables. I want to use the existing Java trsnacoders or the existing C library transcoders. >>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'm missing your point, or vice versa. My point is: if I as a computer create a text file without doing anything special, it will have a particular encoding that is presumably suitable for my language and environment. This default encoding may have been set up by my system administrator or the company that sold me my computer. If I then as a beginning Scheme programmer write a program to read this file, I should not have to use an magic options or commands to do so - it should just work, even if my default encoding is different from with UTF-8. >>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? I can't comment specifically, since SRFI 68 seems to be unavailable: http://srfi.schemers.org/srfi-68/srfi-68.html yields a file not found. But perhaps you could comment on do you expect this to work? Assume I'm Japanese and using some version of JIS. (Or a German using Latin-1, for that matter.) How should my Scheme implementation handle this? -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/