unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: David Kastrup <dak@gnu.org>
Cc: 18520@debbugs.gnu.org
Subject: bug#18520: string ports should not have an encoding
Date: Tue, 23 Sep 2014 21:33:29 +0200	[thread overview]
Message-ID: <8761gew2ra.fsf@gnu.org> (raw)
In-Reply-To: <871tr2joiu.fsf@fencepost.gnu.org> (David Kastrup's message of "Tue, 23 Sep 2014 18:21:45 +0200")

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

David Kastrup <dak@gnu.org> skribis:

> I stated quite definitely that I am perfectly capable of dealing with
> the mess GUILE made of string ports.

Good to know, this was not my understanding until now.

The intent of the change in 2.2 is to hide the very fact that string
ports “have an encoding.”  So from that viewpoint, that bug is closed.

If the bug is about ‘ftell’, that’s a different story.  I would tend to
suggest that ‘ftell’ and ‘seek’ for string ports operate on an abstract
notion of position within the string port data.

This is in fact the path that the R6RS takes:

  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's 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).

Thus, I would suggest a clarification along these lines:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1215 bytes --]

diff --git a/doc/ref/api-io.texi b/doc/ref/api-io.texi
index 02d92a2..8331378 100644
--- a/doc/ref/api-io.texi
+++ b/doc/ref/api-io.texi
@@ -443,8 +443,12 @@ open.
 @deffn {Scheme Procedure} seek fd_port offset whence
 @deffnx {C Function} scm_seek (fd_port, offset, whence)
 Sets the current position of @var{fd_port} to the integer
-@var{offset}, which is interpreted according to the value of
-@var{whence}.
+@var{offset}.  For a file port, @var{offset} is expressed
+as a number of bytes; for other types of ports, such as string
+ports, @var{offset} is an abstract representation of the
+position within the port's data, not necessarily expressed
+as a number of bytes.  @var{offset} is interpreted according to
+the value of @var{whence}.
 
 One of the following variables should be supplied for
 @var{whence}:
@@ -460,7 +464,7 @@ Seek from the end of the file.
 If @var{fd_port} is a file descriptor, the underlying system
 call is @code{lseek}.  @var{port} may be a string port.
 
-The value returned is the new position in the file.  This means
+The value returned is the new position in @var{fd_port}.  This means
 that the current position of a port can be obtained using:
 @lisp
 (seek port 0 SEEK_CUR)

[-- Attachment #3: Type: text/plain, Size: 34 bytes --]


Thoughts?

Thanks,
Ludo’.

  reply	other threads:[~2014-09-23 19:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-21 23:34 bug#18520: string ports should not have an encoding David Kastrup
2014-09-22 11:54 ` Ludovic Courtès
2014-09-22 13:09   ` David Kastrup
2014-09-22 12:21 ` Ludovic Courtès
2014-09-22 13:34   ` David Kastrup
2014-09-22 17:08     ` Ludovic Courtès
2014-09-22 17:20       ` David Kastrup
2014-09-22 20:39         ` Ludovic Courtès
2014-09-22 22:12           ` David Kastrup
2014-09-23  8:25             ` Ludovic Courtès
2014-09-23  9:00               ` David Kastrup
2014-09-23  9:45                 ` Ludovic Courtès
2014-09-23 11:54                   ` David Kastrup
2014-09-23 12:13                     ` Ludovic Courtès
2014-09-23 13:02                       ` David Kastrup
2014-09-23 16:01                         ` Ludovic Courtès
2014-09-23 16:21                           ` David Kastrup
2014-09-23 19:33                             ` Ludovic Courtès [this message]
2014-09-24  5:30 ` Mark H Weaver
2014-09-24 12:00   ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8761gew2ra.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=18520@debbugs.gnu.org \
    --cc=dak@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).