On 2026-06-03 12:14 -0400, Peter McGoron wrote:
> I find it odd that "should" here
>
> > The get-position procedure (if supplied) should return an exact
> integer object representing the current position of the input port.
> If not supplied, the custom port will not support the port-position
> operation.
>
> means (or gets interpreted to mean) that an implementation should
> reject procedures that return non-exact integers, and not that the
> programmer should only write procedures that return exact integer
> objects. (Another reason to dislike R6RS's strictness.)

It's strange wording, and the asymmetry between opaque textual-port
positions and integral binary-port positions seems odd at first.
But I understand where R6RS is coming from: textual ports have
transcoders and buffer modes, which could make positions for different
ports incompatible.  Binary ports lack those complications, so their
positions can be represented simply.

Even though R6RS says very little about port positions, it
would still be incorrect (IMHO) to treat random states as positions.
It's a conceptual mismatch.  The Right Thing here is the idea of
a port facet, i.e. a generic "extra slot" on the port object.
Unfortunately, no one has yet published a SRFI on faceted ports.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>