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