[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: binary vs non-binary ports

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:

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/