Re: byte-order marks

[Andy Wingo]

Hi,

[Ludo and Mark and I scribas]:
>>> * 'open-input-file' could perhaps auto-consume a BOM at the beginning of
>>>   the stream, but *only* if the BOM is already in the encoding specified
>>>   by the user (possibly via an explicit call to 'file-encoding').
>>
>> The problem is that we have no way of knowing what file encoding the
>> user specifies.  The encoding could come from the environment, or from
>> some fluid that some other piece of code binds.  We are really missing
>> an encoding argument to open-file.
>
> Well, ‘%default-port-encoding’ is really an argument to ‘open-file’,
> though admittedly not a convenient one.

Dunno :)  In the end this reduces to saying "the user always specifies a
port encoding".

> However, there’s no way to open a file in binary mode when using
> ‘open-input-file’, ‘call-with-input-file’, etc.

We can add keyword or optional arguments of course.  (Not suggesting
that we do so at this time though.)

>> I liked that my solution "just worked" with a small amount of code and
>> no changes to the rest of the application.  I can't help but think that
>> requiring the user to put in more code is going to infect an endless set
>> of call sites with little "helper" procedures that aren't going to be
>> more correct in aggregate.
>
> For textual files, it doesn’t seem unreasonable for ‘open-input-file’ to
> consume the BOM, IMO.  It’s not much different from the ‘eol-style’
> transcoders.

I could go either way.  I would prefer for open-input-file to consume a
BOM on textual files.  But I have another patch that fixes the (sxml
simple) problem, so I'm also OK with punting on this issue for now.

Andy
-- 
http://wingolog.org/