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.
At Wed, 15 Sep 2004 22:30:04 -1000 (HST), Shiro Kawai wrote: > > Certainly there are implementations that inherently needs to > distinguish character and binary ports, so I see Per's point. I went through the java.io documentation last night to get an idea of how difficult it would be to implement SRFI-56. One interesting thing I discovered was that java.io.RandomAccessFile allows you to intermix reading characters and binary data on the same stream. Using this a Java implementation could easily implement read-byte and read-char, though this would only be for file ports. Also you are limited to internal utf-16 and utf-8 encodings, so if the implementation further wanted to allow arbitrary character encodings you'd have problems. But this means that Java itself does not intend to prevent you from intermixing binary and character data, just that its means of doing so are currently limited. And with the closed nature of the Java core you can't efficiently extend this yourself. If we were to let this influence our design and require specifying whether a port is meant for binary or character data on opening, then Scheme would be in the same weakened position as Java where it cannot efficiently implement other styles of languages. That sort of reasoning would lead Scheme to become the lowest common denominator of implementation techniques. On the other hand, Java is a fairly popular implementation language so it is worth looking at compromises. > I can think of two resolutions. > > (1) changing the phrase in the draft to mention that: > - Some implementations inherently need to distinguish character > and binary ports. > - If the port doesn't support the requested operation, an exception > is raised (already mentioned in the draft). > - The API to distinguish character/binary ports is beyond this srfi This is a little vague, but the first draft did have something similar in reference to string ports saying they may not support binary I/O. > (2) including primitive predicates, something like port-binary-io-capable?, > into this srfi, so that a portable program can be written. Presumably ports could support binary and/or character operations so we'd need separate predicates like binary-port? and character-port?. But without an API for specifying which ports are which you make things less portable, because Schemes which allow intermixing operations will ignore the predicates and Schemes which don't will have to provide their own API's for designating a port type (probably on opening), and these procedures will not be available on other Schemes. A possible way to get more portability is to go ahead and provide the API for specifying port types, such as (open-input-port <path>) ; character port (open-input-port <path> #t) ; binary port or even (open-input-port <path> <encoding>) where <encoding> may be a specific character encoding or something like the Java "binary". Then Schemes who allow freely intermixing binary and character data can ignore the extra arguments, and code written for the other Schemes will work just fine. People writing for more flexible Schemes may be lazy and not specify when they want binary data, but this is easily added when you want to port to other Schemes. The only thing that would be truly non-portable is when you really do need to mix operations on the same port. -- Alex