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.
Shiro Kawai wrote:
There are some implementations that already extend open-{input|output}-file, so I'm afraid that this extention would conflict with them. Cf: http://www.shiro.dreamhost.com/scheme/wiliki/schemexref.cgi/open-input-file http://www.shiro.dreamhost.com/scheme/wiliki/schemexref.cgi/open-output-file
My proposed extension doesn't really conflict with these, certainly not any more than they conflict with otyjer.
Besides, I feel character encoding conversion is much wider topic than the target of this srfi, so I'd rather suggest to leave it to another srfi.
That why I suggest just a encoding name.
If people wish to have the means of ensuring a binary port in portable way, I'd rather have open-binary-{input|output}-file, which can be easily implemented on both (a) implementations that doesn't distinguish binary/character port, and (b) implementations that requires binary/character distinction at port creation.
That does that advantage that it doesn't need existing core library code to be modifed. Plus it may be better "typed" if binary ports have du=iffernt types than character ports. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/