From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marco Maggi Newsgroups: gmane.lisp.guile.devel Subject: Re: binary-port? Date: Sun, 24 Apr 2011 08:39:28 +0200 Message-ID: <87bozwdufz.fsf@rapitore.luna> References: <871v0tudjg.fsf@gnu.org> <87sjt9agb5.fsf@gmx.at> <87liz0yc5l.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1303627039 23745 80.91.229.12 (24 Apr 2011 06:37:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2011 06:37:19 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-15?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 24 08:37:14 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QDswT-0003F4-DE for guile-devel@m.gmane.org; Sun, 24 Apr 2011 08:37:13 +0200 Original-Received: from localhost ([::1]:59603 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDswS-0006ER-K8 for guile-devel@m.gmane.org; Sun, 24 Apr 2011 02:37:12 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDswQ-0006EM-Up for guile-devel@gnu.org; Sun, 24 Apr 2011 02:37:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QDswQ-0007zV-1n for guile-devel@gnu.org; Sun, 24 Apr 2011 02:37:10 -0400 Original-Received: from relay-pt1.poste.it ([62.241.4.164]:46074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QDswO-0007yx-Jx; Sun, 24 Apr 2011 02:37:08 -0400 Original-Received: from rapitore.luna (93.147.76.205) by relay-pt1.poste.it (8.5.121.01) (authenticated as marco.maggi-ipsu@poste.it) id 4DB35A3E00006F05; Sun, 24 Apr 2011 08:37:06 +0200 X-Loop: marco@maggi.it.invalid X-Mailer: GNU Emacs In-Reply-To: <87liz0yc5l.fsf@gnu.org> ("Ludovic =?iso-8859-15?Q?Court=E8s?= =?iso-8859-15?Q?=22's?= message of "Sat, 23 Apr 2011 21:56:38 +0200") Original-Lines: 83 X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-Received-From: 62.241.4.164 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12325 Archived-At: Ludovic Court=A8=A8s wrote: >>> However, I=A1=AFm wondering whether we should not just >>> squarely do away with the binary/textual distinction How would you handle port position? From R6RS[1]: (port-has-port-position? port) procedure (port-position port) procedure The port-has-port-position? procedure returns #t if the port supports the port-position operation, and #f otherwise. For a binary port, the port-position procedure returns the index of the position at which the next byte would be read from or written to the port as an exact non-negative integer object. For a textual port, port-position returns a value of some implementation-dependent type representing the port=A1=AFs position; this value may be useful only as the pos argument to set-port-position!, if the latter is supported on the port (see below). If the port does not support the operation, port-position raises an exception with condition type &assertion. Note: For a textual port, the port position may or may not be an integer object. If it is an integer object, the integer object does not necessarily correspond to a byte or character position. (port-has-set-port-position!? port) procedure (set-port-position! port pos) procedure If port is a binary port, pos should be a non-negative exact integer object. If port is a textual port, pos should be the return value of a call to port-position on port. I do not know how current Guile handles ports; if internally you mark a binary port to handle the position char-wise (so that it is meant to be a textual port) and BINARY-PORT? returns #t: what does GET-U8 do? > Do you know what Industria, Nausicaa, & co. do? Nausicaa uses BINARY-PORT? and TEXTUAL-PORT? only when establishing the conventional class of a port value; as far as I remember it does it in the same way GOOPS does to dispatch multimethods. IMHO this R6 statement: (textual-port? port) procedure=20 (binary-port? port) procedure=20 The textual-port? procedure returns #t if port is textual, and returns #f otherwise. The binary-port? procedure returns #t if port is binary, and returns #f otherwise. should be enough to derive that: (cond ((binary-port? p) ---) ((textual-port? p) ---)) and: (cond ((textual-port? p) ---) ((binary-port? p) ---)) must be equivalent; if they are not, confusion arises because of violation of the rule of least surprise. [1] --=20 Marco Maggi