On 14-Apr-06, at 8:49 AM, John Cowan wrote:

> Marc Feeley scripsit:
>
>> It is a pain to carry those two ports around in the code when the
>> program needs to communicate bidirectionally with some other entity
>> (another process, a user at a terminal, a socket, etc).  Moreover the
>> separation of a conceptually bidirectional channel into distinct
>> ports (input and output) destroys the conceptual link that they
>> have.  This hinders program understanding.  For example, with
>> bidirectional ports (close-port port) will close both sides of the
>> bidirectional port (i.e. the link between the input and output port
>> is preserved).  With two unidirectional ports you have to duplicate
>> some operations (closing ports, changing port settings, ...).
>
> I find this rationale convincing (and think it should be added to the
> SRFI).

OK.

>   However, the socket API does permit closing input and output
> sides of the socket separately, and there are use cases for this,
> so it
> should be at least permitted though not the default.
>
> For example, when you want to send an arbitrary-length undecorated
> document to a server and retrieve an arbitrary-length undecorated
> document
> back, the simplest way to convey "end of document" is to close the
> output
> side, while leaving the input side open in order to receive the reply.
>

That was the intent of the passage:

     When an operation is said to apply to an input port it also
applies to a
     bidirectional port.  When an operation is said to apply to an
output port
     it also applies to a bidirectional port.

but I guess it is not clear that this also applies to the port
closing operations so I will add a note to that effect.  So yes you can:

    (let ((tty (open-file "/dev/tty"))) ; bidirectional port
      ...
      (close-input-port tty)
      ...
      (close-output-port tty))

And similarly for any bidirectional port (presumably sockets when
they are specified by another SRFI).  For the record Gambit has:

    (open-tcp-client
      (list server-address: "www.apple.com"
            port-number: 80
            eol-encoding: 'cr-lf)))

> A few unrelated editorial comments:
>
> UTF-8 byte sequences of length 5 and 6 have been deprecated for a
> long,
> long time.  They should not be referred to here.
>

This is an oversight.  I'll change it to 1 to 4 bytes.  That's what
my reference implementation does anyway.

> The SRFI should explicitly permit implementation-dependent encodings
> and eol-encodings.  (XML 1.1 allows CR, LF, CR/LF, NEL=U+0085, and
> LS=U+2028.)

What do you mean by "explicitly permit"?  In general an
implementation can extend an API any way it wishes!  The spec is only
a requirement.

>
> The SRFI should depend only on the lighter-weight SRFI 66 (Octet
> vectors),
> rather than on the heavier-weight SRFI 4.

It only depends on u8vectors which are common in SRFI 4 and SRFI 66.
SRFI 66 has things that SRFI 4 does not have, and vice versa.  I
could add a reference to SRFI 66 though.

>
> A warning is needed that non-default values of the create: file port
> setting may be subject to race conditions on file systems that
> don't provide full Posix semantics.
>

Sounds reasonable, as a warning.

> Finally, this SRFI makes only trivial use of keyword objects, and IMHO
> should be respecified to use symbols to reduce its dependencies.

I'll add something in the preamble saying:

    The tokens of the form ``foo:'' used in this document will be
called ``keywords''.
    On Scheme implementations supporting SRFI 88, these keywords
correspond to the
    keyword objects specified in that SRFI.  On Scheme
implementations which do not
    support SRFI 88, these keywords are symbols.

Marc