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/
