Michael Sperber wrote:
> Per Bothner <xxxxxx@bothner.com> writes:
>>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.
>
> Sure.  I'm only pointing out that a notion of "default encoding" may
> not exist on your platform, or that it may not be reasonable, even for
> "default" cases, to enforce one upon the application.

"Default encoding" may vary from user to user (at least on Unix-like
platforms). And if each file includes an "encoding" attribute,
then there is less need for the concept of a default encoding.
But the concept is still needed, to specify the encoding to be
used when creating a new text file, and to define an implicit
encoding for existing text files without an encoding attribute.

> Specifically,
> the "default encoding" may be different for files (or for files in
> different file systems) and the console.

It could be.  I don't think that's a problem.
>
>>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?
>
>
> Make (standard-input-port) and frieds return suitable transcoded
> ports.  I think you probably want this to work for files as well, but
> I don't think it makes sense there, as explained above.

I disagree.  open-output-file should create a file using the
default encoding.  And when open-input-file read a file, if the
platform doesn't supply an encoding attribute, it should use
the default one.

Let me emphasize again: It is essential that open-output-file
create a file using the same encoding that the rest of my
environment expects.  I should be able to open the file
using my default editor.  If I cat/type/view the file, my
terminal should display the correct glyphs, and not be garbled.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/