On Thu, Mar 19, 2020 at 6:16 AM Shiro Kawai <xxxxxx@gmail.com> wrote:

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 were originally part of the pre-SRFI version of SRFI 186, but I removed them for conceptual integrity.   They will be in another R6RS extracted SRFI when I get a chance.

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
I've added that to my repo.
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

I've also added this. 

(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?)

In that case the positions might as well be vector indexes.  Textual positions can be any Scheme value that makes sense.

On Thu, Mar 19, 2020 at 6:25 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> 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.

In addition, if the textual port is processing text in a stateful encoding such as ISO 2022, it's necessary for the position to carry the current state.  For full ISO 2022 support, you need at a bare minimum the position in the byte stream. plus four exact integers specifying the four codesets that ISO 2022 allows to be available at the same time, plus flags indicating which of these four sets are actually in use to interpret input bytes in the four ranges 01-1F, 21-7E, 80-9F, and A0-FF.  (The bytes 00, 20, 7F are always NUL, space, DEL respectively.)
I'd also like to suggest to add a state flag "fold-case?" to each textual (input) port.

That way madness lies. Larceny textual input ports, for example, have not only a fold-case flag but lexical syntax flags for R7RS, R6RS, Larceny, and deprecated Larceny.

Without it, one cannot implement the `read' procedure of `(scheme base)' in a portable way.

I don't know why that should be; can you explain?

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
I come from under the hill, and under the hills and over the hills my paths
led. And through the air. I am he that walks unseen.  I am the clue-finder,
the web-cutter, the stinging fly. I was chosen for the lucky number.  --Bilbo