Yes, I think that's the intention that R6RS didn't specify the type of the position of textual port.

Do you (or anybody) know how to write a portable textual input port with port-position capability, if 
the position info is implementation dependent?   Like the example I mentioned, a textual port
read from a character vector, which should be naturally "positionable".

On Thu, Mar 19, 2020 at 12:25 AM Marc Nieper-Wißkirchen <> wrote:
Limiting the position to be an integer is a bit, err, limiting. For many purposes, we would also like to record the current line and column numbers.
I'd also like to suggest to add a state flag "fold-case?" to each textual (input) port. Without it, one cannot implement the `read' procedure of `(scheme base)' in a portable way.


Am Do., 19. März 2020 um 11:16 Uhr schrieb Shiro Kawai <>:
I'm implementing srfi-181 and portable tests for it, and noticed that  the description of get-position and set-position refers to r6rs port-position and set-port-position!, which haven't been defined in r7rs or other srfi so far (unless I overlooked one).

They could be in a coming srfi, but it may be nice to have a reference to a definite
specification (e.g. r6rs) even though it is implied by the fact that the spec is from

In r6rs, port-position returns an object of implementation-dependent type, not
necessarily an integer, for textual ports.
Correspondingly, get-position of make-custom-textual-*-port
doesn't specify the return type.  srfi-181 draft 2 limits get-position to return
an exact integer.  If we follow the semantics of r6rs port-position, we need to resolve

(It is actually not clear to me that,  in r6rs, how the return value of get-position for
a textual port is related to the one returned by port-position.  For example, when
you're writing a textual port that reads from a vector of characters, how do you
implement get-position/set-position?)