Why are byte ports "ports" as such?
Ben Goetter
(13 Apr 2006 17:54 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(13 Apr 2006 18:04 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(13 Apr 2006 21:41 UTC)
|
||
Re: Why are byte ports "ports" as such? John Cowan (14 Apr 2006 12:49 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(14 Apr 2006 13:37 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(13 Apr 2006 22:03 UTC)
|
||
Re: Why are byte ports "ports" as such?
Ben Goetter
(14 Apr 2006 01:02 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(14 Apr 2006 01:52 UTC)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
Re: Why are byte ports "ports" as such?
Marcin 'Qrczak' Kowalczyk
(24 May 2006 16:17 UTC)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
Re: Why are byte ports "ports" as such?
Thomas Bushnell BSG
(24 May 2006 16:26 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(24 May 2006 17:18 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(24 May 2006 18:11 UTC)
|
||
(missing)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(24 May 2006 16:06 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(14 Apr 2006 12:26 UTC)
|
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). 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. 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. 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.) The SRFI should depend only on the lighter-weight SRFI 66 (Octet vectors), rather than on the heavier-weight SRFI 4. 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. Finally, this SRFI makes only trivial use of keyword objects, and IMHO should be respecified to use symbols to reduce its dependencies. -- John Cowan xxxxxx@ccil.org http://ccil.org/~cowan This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman